some issues with /usr/sbin/service
Jeremy Chadwick
jdc at koitsu.org
Sat Feb 16 09:21:35 UTC 2013
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 at koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
More information about the freebsd-stable
mailing list