Date: Fri, 15 Feb 2013 19:17:31 -0500 From: Gary Palmer <gpalmer@freebsd.org> To: Jeremy Chadwick <jdc@koitsu.org> Cc: freebsd-stable@FreeBSD.org, Alfred Bartsch <bartsch@dssgmbh.de> Subject: Re: some issues with /usr/sbin/service Message-ID: <20130216001731.GD85777@in-addr.com> In-Reply-To: <20130215212020.GA17516@icarus.home.lan> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 15, 2013 at 01:20:20PM -0800, Jeremy Chadwick wrote:
> On Fri, Feb 15, 2013 at 02:32:10PM -0500, Gary Palmer wrote:
> > On Fri, Feb 15, 2013 at 02:57:10AM -0800, Jeremy Chadwick wrote:
> > > On Fri, Feb 15, 2013 at 11:26:11AM +0100, Alfred Bartsch wrote:
> > > > we want to use this script for server administration purposes. After
> > > > doing some testing, for now there are following issues left:
> > > >
> > > > 1) every execution of "service -e" casts a bunch of unnecessary
> > > > warnings into /var/log/messages:
> > > > "... /usr/sbin/service: WARNING: $<name>_enable is not set
> > > > properly - see rc.conf(5)."
> > > > This is caused by calling "checkyesno()", provided by /etc/subr. It
> > > > could be solved by using a local function, named "checkyes" or similar.
> > > >
> > > > The following patch prohibits these annoying messages:
> > > > {snip}
> > >
> > > Your patch, in effectively, "rewrites" checkyesno() to remove the warn()
> > > call in cases where xxx_enable variables are set to values other than
> > > yes/true/on/1 or no/false/off/0.
> > >
> > > Here's a better idea:
> > >
> > > Fix your /etc/rc.conf xxx_enable variables which contain values that
> > > aren't permitted. That's what the warn() is for -- to tell you to fix
> > > them. :-)
> >
> > It also warns if xxx_enable isn't set. I have a number of ports installed
> > which I don't want to run by default but may run later, or which have
> > daemons but I don't want the daemon but some other functionality.
> > rsync and fetchmail are two perfect examples of the latter.
> >
> > If I don't have xxx_enable in /usr/local/etc/rc.conf I get the warning.
> > Should I really have to go through and explicitly set the xxx_enable flags
> > to "no"? Or should the code be smart enough to recognise that the variable
> > not being present is equivalent to "no"?
> >
> > If the requirement is that all installed rc.d scripts have a xxx_enable flag
> > set to yes or no at all times, then the current ports infrastructure is sadly
> > lacking as I don't have anything under /usr/local/etc/defaults/ at all (if
> > that is even a valid location). And I'd prefer ports not try and automagically
> > frob /etc/rc.conf, /etc/rc.conf.local or /etc/defaults/rc.conf to add/remove
> > xxx_enable lines as that can go wrong.
>
> This is the first I've heard of something called /usr/local/etc/rc.conf.
Sorry, my brain was ahead of where my fingers were and got the path
wrong. I of course meant /etc/rc.conf.
> Regardless, I can't confirm that behaviour:
As you found, it gets logged rather than output to stdout or stderr.
Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $xfs_enable is not set properly - see rc.conf(5).
Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $rsyncd_enable is not set properly - see rc.conf(5).
Feb 15 19:21:18 desktop gpalmer: /usr/sbin/service: WARNING: $rrdcached_enable is not set properly - see rc.conf(5).
(etc)
I've come across something else outputing that error, but it probably
all comes from the same place. Either the rc processor needs to treat
the flag not being set as equal to "no", or the ports infrastructure needs
to start installing something to make foo_enable="no" appear in the
defaults system somewhere
Gary
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130216001731.GD85777>