Date: Sat, 16 Feb 2013 18:24:20 +0000 From: Chris Rees <crees@FreeBSD.org> To: Gary Palmer <gpalmer@freebsd.org> Cc: Jeremy Chadwick <jdc@koitsu.org>, FreeBSD <freebsd-stable@freebsd.org>, Boris Samorodov <bsam@passap.ru> Subject: Re: some issues with /usr/sbin/service Message-ID: <CADLo83-yq-2PhAoTjaNSKGLnP1djpFXZvv3BN%2BUOP030bGNe9g@mail.gmail.com> In-Reply-To: <20130216180859.GF85777@in-addr.com> 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> <1FD54589-7C32-47B5-A400-02FEE1459B02@gromit.dlib.vt.edu> <CADLo83972a=yv_dGNazNywFpF22vJGVG_sMVYVDAMM7BnQXwpA@mail.gmail.com> <20130216180859.GF85777@in-addr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 February 2013 18:08, Gary Palmer <gpalmer@freebsd.org> wrote:
> On Sat, Feb 16, 2013 at 05:38:56PM +0000, Chris Rees wrote:
>> On 16 February 2013 17:05, Paul Mather <paul@gromit.dlib.vt.edu> wrote:
>> > 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 fi=
nd
>> >>>> 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_e=
nable is not set properly - see rc.conf(5).
>> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_ena=
ble is not set properly - see rc.conf(5).
>> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_ena=
ble is not set properly - see rc.conf(5).
>> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcachecle=
an_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 sourc=
e
>> >> 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=3D"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 u=
p
>> >>> 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 nee=
d
>> >> to set xxx_enable=3D"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=3D"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 is=
n't
>> >> "reminding" an administrator -- if anything it's confusing them (thre=
ad
>> >> 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=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 O=
S 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 wil=
l 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.
>>
>> With few exceptions, it should be considered a rule that ports rc
>> scripts contain:
>>
>> : ${xxx_enable=3Dno}
>>
>> to avoid this. If you see any ports that don't define the _enable
>> variable at all, they are wrong and need fixing.
>
> Except the 'service' command doesn't parse the individual ports rc.d
> script so the default is never found. It relies purely on rc.conf and
> rc.conf.local settings.
>
> So no matter if the port has
>
> : ${xxx_enable=3Dno}
>
> or not, 'service -e' will still spit out the warnings
>
> Not loading the individual ports files is probably done for two reasons
> I can think of - performance, and safety (in case the rc.d file is bad
> for some reason). However it leads to these rather irritating
> warnings, especially when you find them later and you don't know what
> you did to cause them.
>
> I was away to suggest that having /usr/local/etc/rc.conf.d would help
> as ports could then specify their defaults safely without having to do
> file rewrites, however that appears to be only looked at in
> load_rc_config(), and 'service -e' bypasses that as well by doing
>
> load_rc_config 'XXX'
>
> so only /usr/local/etc/rc.conf.d/xxx would be looked at.
Yes, OK. A variation on Alfred's checkyes patch is at [1].
I have not made it into a function deliberately because this is
already rc idiom as used in other rc scripts where a warning is not
necessary, and also because it is very rarely the right thing to do
(i.e. it would be tempting to overuse it if it were a function).
Chris
[1] http://www.bayofrum.net/~crees/patches/service-no-logging.diff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo83-yq-2PhAoTjaNSKGLnP1djpFXZvv3BN%2BUOP030bGNe9g>