Date: Sat, 16 Feb 2013 01:21:33 -0800 From: Jeremy Chadwick <jdc@koitsu.org> To: Boris Samorodov <bsam@passap.ru> Cc: freebsd-stable@FreeBSD.org Subject: Re: some issues with /usr/sbin/service Message-ID: <20130216092133.GA31449@icarus.home.lan> In-Reply-To: <511F4205.50509@passap.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <missing xxx_enable in rc.conf> 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 <no definition> 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 <no xxx_enable definition> 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 |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130216092133.GA31449>