From owner-freebsd-questions@FreeBSD.ORG Thu Jan 1 22:25:37 2015 Return-Path: Delivered-To: freebsd-questions@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 729A2F44 for ; Thu, 1 Jan 2015 22:25:37 +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 3D7E6646FA for ; Thu, 1 Jan 2015 22:25:36 +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 A478D2EF0 for ; Thu, 1 Jan 2015 23:25:35 +0100 (CET) Date: Thu, 1 Jan 2015 23:25:34 +0100 From: Daniel Koester To: freebsd-questions@freebsd.org Subject: service -R (restart) and [/usr/local]/etc/rc.conf.d/ Message-ID: <20150101222533.GC40862@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-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 22:25:37 -0000 Hello, I posted the message below to freebsd-rc 2 weeks ago, but sadly haven't received any answer yet, I hope it is ok to repost it here, maybe somebody has an idea. The gist: 'service -R' ignores '/etc/rc.conf.d/' Kind Regards, DK Sent to freebsd-rc@ at Tue Dec 16 00:02:56 UTC 2014: ==================================================== 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