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@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
> r...@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.
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 j...@koitsu.org |
| UNIX Systems Administrator http://jdc.koitsu.org/ |
| Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
