some issues with /usr/sbin/service

Fri Feb 15 21:32:58 UTC 2013

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.
> 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 at icarus:~ # grep mysql_ /etc/rc.conf
> # mysql_enable="yes"
> # mysql_dbdir="/storage/mysql"
> 
> root at 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 at icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64  amd64
> 
> root at 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.

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_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).

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).

2) These messages should not be displayed at all (i.e. lack of an
xxx_enable variable should imply xxx_enable="no").

I'll file a PR for this.

-- 
| Jeremy Chadwick                                   jdc at koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |