From owner-freebsd-rc@FreeBSD.ORG Tue Dec 16 00:02:56 2014 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 514BD4C0 for ; Tue, 16 Dec 2014 00:02:56 +0000 (UTC) Received: from hyve.org (hyve.org [IPv6:2001:41d0:a:1794:2a:17:dead:beef]) by mx1.freebsd.org (Postfix) with ESMTP id 1CEB82F for ; Tue, 16 Dec 2014 00:02:55 +0000 (UTC) Received: from dk.hyve.org (hyve.org [IPv6:2001:41d0:a:1794:2a:17:dead:beef]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hyve.org (Postfix) with ESMTPSA id 6BBCA7362 for ; Tue, 16 Dec 2014 01:02:54 +0100 (CET) Date: Tue, 16 Dec 2014 01:02:52 +0100 From: Daniel Koester To: freebsd-rc@freebsd.org Subject: service -R (restart) and [/usr/local]/etc/rc.conf.d/ Message-ID: <20141216000252.GB40862@dk.hyve.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 00:02:56 -0000 Hello FreeBSD-rc Readers, this issue has left me confused now for quite some time and has (for me) persisted since 8.* all the way up to 10.1-RELEASE-p1: The rc system supports the '[/usr/local]/etc/rc.conf.d/' directory to place small files, e.g. for '/etc/rc.conf.d/inetd' containing 'inetd_enable="YES"'. This works perfectly well at startup, i.e, at boot time the system will actually start 'inetd', no problem there. However, when calling 'service -e', '/etc/rc.d/inetd' will NOT be listed (although it will be listed when calling 'service -l'). Furthermore, and this is the root cause of this inquiry, 'service -R' will NOT stop and start 'inetd', as one would expect it to do. The bug tracker shows a few somewhat related bug reports, which are mostly still open (some for years ;-), e.g.: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=173454 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167822 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=141909 Each script in '[/usr/local]/etc/rc.d/' seems to call 'load_rc_config $name' with '$name' properly set, so when using '/etc/rc.d/$name ' everything works as expected. Now, am I (ab)using the rc system in any wrong way or expecting a wrong kind of behaviour from 'service -R', or might there be a bug. I looked at '/usr/sbin/service' and noticed the following lines: . /etc/rc.subr load_rc_config 'XXX' 'load_rc_config' seems to search for a config file (also a directory) in '/etc/rc.conf.d/XXX'. It seems the 'XXX' argument was simply used to prevent the 'load_rc_config' call to exit with an error: ERROR: USAGE: load_rc_config name Can we (ab)use this behaviour? Sure, we can, renaming 'inetd' to 'XXX' in that directory works as expected, as does creating directory 'XXX' and placing the 'inetd' file in there (in both cases, 'service -R' restarts inetd and 'service -e' lists '/etc/rc.d/inetd'). Putting the line from the 'inetd' file into '/etc/rc.conf.local' also works as expected... Still, it would be nice to separate service configurations in '/etc/rc.conf.d'. I'm really sorry if this has been asked before, I searched for it on the bug tracker and the mailing list search, but could not really find any definitive answer as to the root cause of this behaviour or a suggested fix (in my usage pattern). So at this point either there's a bug somewhere (which I'm very much willing to help fix), or I'm simply using it the wrong way (in which case please feel obliged to correct me). Maybe/hopefully somebody can chime in and help me... Kind regards and keep up the awesome work, DK