some issues with /usr/sbin/service

Boris Samorodov bsam at passap.ru
Sat Feb 16 11:44:43 UTC 2013


16.02.2013 13:21, Jeremy Chadwick пишет:
> 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):
[...]
>>> 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.

That's it. But I call it "one more level of supervision" on purpose.
There may be many sisadmins at one system and there may be many systems
at one sysadmin. We are humans and make mistakes. One more level of
supervision won't hurt.

> If so: I strongly disagree with this method of approach, as what you've
> proposed is a borderline straw man argument.

Got ypour POV.

> 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.

"The message is is entirely misleading" -- yes, agreed! It should be
reworded. ;-)

> 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

As I've said for system it is already that. But warnings are for
humans. And I think that case 2) and 4) are entirely different.
I'd rather see the current behavour at 4) but with better explanation.

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve


More information about the freebsd-stable mailing list