From owner-freebsd-stable@FreeBSD.ORG Sat Feb 16 00:17:33 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F2667EFB; Sat, 16 Feb 2013 00:17:32 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id AED70F5D; Sat, 16 Feb 2013 00:17:32 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U6VT9-000GbI-Gr; Fri, 15 Feb 2013 19:17:31 -0500 Date: Fri, 15 Feb 2013 19:17:31 -0500 From: Gary Palmer To: Jeremy Chadwick Subject: Re: some issues with /usr/sbin/service Message-ID: <20130216001731.GD85777@in-addr.com> References: <511E0D43.6070900@dssgmbh.de> <20130215105710.GA6130@icarus.home.lan> <20130215193210.GB85777@in-addr.com> <20130215212020.GA17516@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130215212020.GA17516@icarus.home.lan> X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-stable@FreeBSD.org, Alfred Bartsch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 00:17:33 -0000 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: $_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