Date: Fri, 15 Feb 2013 13:20:20 -0800 From: Jeremy Chadwick <jdc@koitsu.org> To: Gary Palmer <gpalmer@freebsd.org> Cc: freebsd-stable@FreeBSD.org, Alfred Bartsch <bartsch@dssgmbh.de> Subject: Re: some issues with /usr/sbin/service Message-ID: <20130215212020.GA17516@icarus.home.lan> In-Reply-To: <20130215193210.GB85777@in-addr.com> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
What is this file? I don't see it mentioned as being read/used by
rc_conf_files (see /etc/defaults/rc.conf), at least not via stock. Are
you redefining rc_conf_files or are you somehow source'ing the file
yourself?
Regardless, I can't confirm that behaviour:
root@icarus:~ # grep mysql_ /etc/rc.conf
# mysql_enable="yes"
# mysql_dbdir="/storage/mysql"
root@icarus:~ # service -e
/etc/rc.d/hostid
/etc/rc.d/zvol
/etc/rc.d/ddb
/etc/rc.d/hostid_save
/etc/rc.d/zfs
/etc/rc.d/cleanvar
/etc/rc.d/ip6addrctl
/etc/rc.d/devd
/etc/rc.d/netwait
/etc/rc.d/newsyslog
/etc/rc.d/syslogd
/etc/rc.d/named
/etc/rc.d/ntpdate
/etc/rc.d/dmesg
/etc/rc.d/virecover
/etc/rc.d/motd
/etc/rc.d/ntpd
/etc/rc.d/powerd
/usr/local/etc/rc.d/samba
/usr/local/etc/rc.d/postfix
/usr/local/etc/rc.d/apache22
/etc/rc.d/sshd
/etc/rc.d/cron
/etc/rc.d/mixer
/etc/rc.d/inetd
/etc/rc.d/gptboot
Same goes for if I removed the commented-out lines (shouldn't matter but
I tested it anyway).
System:
FreeBSD icarus.home.lan 9.1-STABLE FreeBSD 9.1-STABLE #0 r246644: Sun Feb 10 16:55:49 PST 2013 root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64 amd64
root@icarus:~ # grep '$FreeBSD' /etc/rc /etc/rc.subr
/etc/rc:# $FreeBSD: stable/9/etc/rc 233943 2012-04-06 11:07:44Z ed $
/etc/rc.subr:# $FreeBSD: stable/9/etc/rc.subr 243754 2012-12-01 15:46:27Z crees $
I fully agree that if this were the case (having to set xxx_enable="no"
explicitly) that would be a bug.
--
| Jeremy Chadwick jdc@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130215212020.GA17516>