From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 09:21:35 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B1B8B24C for ; Sat, 16 Feb 2013 09:21:35 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by mx1.freebsd.org (Postfix) with ESMTP id 941E1173 for ; Sat, 16 Feb 2013 09:21:35 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta05.emeryville.ca.mail.comcast.net with comcast id 0xMa1l0011HpZEsA5xMaNH; Sat, 16 Feb 2013 09:21:34 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta14.emeryville.ca.mail.comcast.net with comcast id 0xMZ1l0081t3BNj8axMZHs; Sat, 16 Feb 2013 09:21:34 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A2FFD73A1C; Sat, 16 Feb 2013 01:21:33 -0800 (PST) Date: Sat, 16 Feb 2013 01:21:33 -0800 From: Jeremy Chadwick To: Boris Samorodov Subject: Re: some issues with /usr/sbin/service Message-ID: <20130216092133.GA31449@icarus.home.lan> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> <20130215213257.GA20155@icarus.home.lan> <511F4205.50509@passap.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <511F4205.50509@passap.ru> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361006494; bh=UwkynGc+x64NoQfxBEeY1B3Dp4cU77PsK9Q81SdixhQ=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=XCYQnYW8JrlF0WlRutHc2yfZyLW2xkx79VTyZnYbbGS/D3ckwUWb8ftMcHNWIDoZP JIGEWFB5El5+iIx23FhLFwF29zHaA54vmL3jiirmnqmJfXdUP1h7tmcjUWEp2whvpl 4R3vo5rtPSm+gkYMWohuGiiFauF7CsmtaBfsBHxtAphfE6Dzn2IQIf+hrVAgDnlShX 6H8P8EtF1cJK3G71Z6ZUnFJmsX1tlaHTmRZsl528jBGNWjbCTeUhpZ+fqFwhtksGtB V4p8+fFzNQnGHZpmcR8SxUJPWLKeU+YjVoS4Mqw2swCkVP0FmxS3NfZ0HFkgSSf80Y UPzI4M8856n3g== Cc: freebsd-stable@FreeBSD.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 09:21:35 -0000 On Sat, Feb 16, 2013 at 12:23:33PM +0400, Boris Samorodov wrote: > 16.02.2013 01:32, Jeremy Chadwick ??????????: > > > Follow up -- I read Alfred's most recent mail. Lo and behold, I find > > this in /var/log/messages (but such did not come to my terminal): > > > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $svnserve_enable is not set properly - see rc.conf(5). > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enable is not set properly - see rc.conf(5). > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5). > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclean_enable is not set properly - see rc.conf(5). > > Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_enable is not set properly - see rc.conf(5). > > > > Cute. Agreed -- this is unacceptable on two levels (as I see it): > > > > 1) These messages should be going to stdout or stderr in some way, so > > honestly logger(8) should be called with the "-s" flag (IMO). > > Fully agreed here. It turns out logger -s has no effect, just like how the echo 1>&2 statements in warn() and err() have no effect either (these should be outputting the warnings in question to stderr) -- see rc.subr's source for what I'm referring to. Gary and I have been discussing this off-list and the reason has been found: service(8) has this code in it: checkyesno $rcvar 2>/dev/null && echo $file This explains why there's no warn() or err() output on the terminal -- it's being redirected to /dev/null prior. I do not know who maintains the rc(8) and rc.subr(8) framework, but they've got their work cut out for them. (Note: the echo statements in warn() and err() could be replaced with "logger -s" as I said; this would allow the "echo 1>&2" to be removed) > > 2) These messages should not be displayed at all (i.e. lack of an > > xxx_enable variable should imply xxx_enable="no"). > > I see this message as one more level of supervision. > > If undefined at /etc/make.conf the value of xxx_enable is "no" from the > system's POV (i.e. the service is not strarted). From the > admininstrators's POV the port was installed BUT is not used. It's up > to admininstrator whether it's OK or not -- just let him remind. I believe the point you're trying to make is that the warning in question should 'act as a reminder to the administrator that they need to set xxx_enable="yes" in rc.conf'. If not: please explain if you could what you mean, because I don't understand. If so: I strongly disagree with this method of approach, as what you've proposed is a borderline straw man argument. Reminding the admin to set xxx_enable is presently done inside most ports' pkg-message. IMO, this should really be done inside bsd.port.mk when USE_RC_SUBR is used, emitting a message during install that says something like: To enable the xxx service, please add the following to /etc/rc.conf: xxx_enable="yes" Of course, I don't know if this would work for packages. The current message for is this: WARNING: $xxx_enable is not set properly - see rc.conf(5). The message is entirely misleading for this specific situation; it isn't "reminding" an administrator -- if anything it's confusing them (thread is case in point). If we're going to cater to ignorance, then the message should reflect the situation. Thus IMO, this is what ***should*** happen: Definition in rc.conf Behaviour/result ----------------------- ------------------------------------------- myprog_enable="yes" emit no warnings, service should run myprog_enable="no" emit no warnings, service should not run myprog_enable="abc123" emit a warning, service should not run emit no warnings, service should not run It's too bad FreeBSD doesn't have a real services framework like Solaris's smf/svccfg/svcs/svcadm, which in itself alleviates this entire situation. Services are registered with svccfg during installation; there's no config file, thus no chance of a situation. This software also comes to mind (folks who think systemd is a great solution should read the 2nd link): http://www.skarnet.org/software/s6/index.html http://www.skarnet.org/software/s6/why.html -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |