Date: Sat, 16 Feb 2013 18:13:00 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Gary Palmer <gpalmer@freebsd.org>, Chris Rees <crees@FreeBSD.org> Cc: Jeremy Chadwick <jdc@koitsu.org>, Boris Samorodov <bsam@passap.ru>, FreeBSD <freebsd-stable@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com> Subject: RE: some issues with /usr/sbin/service Message-ID: <13CA24D6AB415D428143D44749F57D7201EAA456@ltcfiswmsgmb21> 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
(sorry for top-post ... dumb client software)
Am I missing something in this entire thread or...
Why not utilize the oft-neglected "/etc/rc.conf.d" directory?
Example? My own "vimage" package which installs:
/etc/rc.conf.d/vimage
/etc/rc.d/vimage
The /etc/rc.conf.d file is a segment of what should appear in /etc/defaults=
/rc.conf.d and is loaded whenever a service is loaded. The /etc/rc.conf.d a=
cts as a set of underrides just like /etc/defaults/rc.conf does for the res=
t of the rc system.
--=20
Devin
________________________________________
From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] o=
n behalf of Gary Palmer [gpalmer@freebsd.org]
Sent: Saturday, February 16, 2013 10:08 AM
To: Chris Rees
Cc: Jeremy Chadwick; FreeBSD; Boris Samorodov
Subject: Re: some issues with /usr/sbin/service
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 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_en=
able is not set properly - see rc.conf(5).
> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $smartd_enab=
le is not set properly - see rc.conf(5).
> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $rsyncd_enab=
le is not set properly - see rc.conf(5).
> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $htcacheclea=
n_enable is not set properly - see rc.conf(5).
> >>>> Feb 15 13:26:20 icarus jdc: /usr/sbin/service: WARNING: $fetchmail_e=
nable 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=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 t=
he
> >>> 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=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 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=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". T=
he net/avahi-app port, for example, doesn't default to "NO" if xxx_enable i=
s not set: it defaults to whatever the gnome_enable setting is defined to b=
e.
>
> 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.
Gary
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
_____________
The information contained in this message is proprietary and/or confidentia=
l. If you are not the intended recipient, please: (i) delete the message an=
d all copies; (ii) do not disclose, distribute or use the message in any ma=
nner; and (iii) notify the sender immediately. In addition, please be aware=
that any message addressed to our domain is subject to archiving and revie=
w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7201EAA456>