some issues with /usr/sbin/service

[Jeremy Chadwick]

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.

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