some issues with /usr/sbin/service

[Paul Mather]

On Feb 16, 2013, at 4:21 AM, Jeremy Chadwick wrote:

> 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


I think case 4 ("<no definition>") is a case where a warning should be emitted because it is arguably not immediately apparent what will actually happen if no definition is present.  In the case of services in the base OS it is well-defined: every service should have an explicit default in /etc/defaults/rc.conf that you can easily consult to know definitively what will happen with that service.  (If it doesn't, that is a bug, IMHO.)

For ports, the case is not so clear.  There is a general trend for the port rc.d script to default its respective xxx_enable explicitly to "NO".  But it is not a universal rule that "no definition" = default to "NO".  The net/avahi-app port, for example, doesn't default to "NO" if xxx_enable is not set: it defaults to whatever the gnome_enable setting is defined to be.

For the base OS, I agree with your case 4; for the land of ports, I don't think the answer is so cut and dried.  That is why I think the warning is useful: it reminds admins to look at the service in question and make a firm decision of their own as to whether it should explicitly be turned on or off.  It is a reminder to configure the service properly and remove ambiguity.

(I also personally find the warnings a useful reminder of services that are candidates for removal on the grounds that they appear never to have been configured.)

Cheers,

Paul.