Date: Sat, 16 Feb 2013 12:05:57 -0500 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Jeremy Chadwick <jdc@koitsu.org> Cc: freebsd-stable@FreeBSD.org, Boris Samorodov <bsam@passap.ru> Subject: Re: some issues with /usr/sbin/service Message-ID: <1FD54589-7C32-47B5-A400-02FEE1459B02@gromit.dlib.vt.edu> In-Reply-To: <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> <20130216092133.GA31449@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ??????????:
>>=20
>>> 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):
>>>=20
>>> 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).
>>>=20
>>> Cute. Agreed -- this is unacceptable on two levels (as I see it):
>>>=20
>>> 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).
>>=20
>> Fully agreed here.
>=20
> 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.
>=20
> Gary and I have been discussing this off-list and the reason has been
> found: service(8) has this code in it:
>=20
> checkyesno $rcvar 2>/dev/null && echo $file
>=20
> This explains why there's no warn() or err() output on the terminal --
> it's being redirected to /dev/null prior.
>=20
> I do not know who maintains the rc(8) and rc.subr(8) framework, but
> they've got their work cut out for them.
>=20
> (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)
>=20
>>> 2) These messages should not be displayed at all (i.e. lack of an
>>> xxx_enable variable should imply xxx_enable=3D"no").
>>=20
>> I see this message as one more level of supervision.
>>=20
>> 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). =46rom 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.
>=20
> 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=3D"yes" in rc.conf'.
>=20
> If not: please explain if you could what you mean, because I don't
> understand.
>=20
> If so: I strongly disagree with this method of approach, as what =
you've
> proposed is a borderline straw man argument.
>=20
> 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:
>=20
> To enable the xxx service, please add the following to /etc/rc.conf:
> xxx_enable=3D"yes"
>=20
> Of course, I don't know if this would work for packages.
>=20
> The current message for <missing xxx_enable in rc.conf> is this:
>=20
> WARNING: $xxx_enable is not set properly - see rc.conf(5).
>=20
> 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.
>=20
> Thus IMO, this is what ***should*** happen:
>=20
> Definition in rc.conf Behaviour/result
> ----------------------- -------------------------------------------
> myprog_enable=3D"yes" emit no warnings, service should run
> myprog_enable=3D"no" emit no warnings, service should not run
> myprog_enable=3D"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" =3D 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1FD54589-7C32-47B5-A400-02FEE1459B02>