From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 31 17:38:03 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1B5F16A417 for ; Fri, 31 Aug 2007 17:38:03 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from secure.socket.ch (secure.socket.ch [212.103.70.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4D77E13C4DA for ; Fri, 31 Aug 2007 17:38:03 +0000 (UTC) (envelope-from freebsd.lists@fsck.ch) Received: from 80-219-162-83.dclient.hispeed.ch ([80.219.162.83] helo=factory.fsck.ch) by secure.socket.ch with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1IR9pn-000DyY-CP; Fri, 31 Aug 2007 18:59:05 +0200 Message-ID: <46D848D6.3030006@fsck.ch> Date: Fri, 31 Aug 2007 18:59:02 +0200 From: Tobias Roth User-Agent: Thunderbird 2.0.0.6 (X11/20070804) MIME-Version: 1.0 To: Sean Bruno References: <46D84609.3080409@miralink.com> <46D84697.800@fsck.ch> <46D8470B.9030304@miralink.com> In-Reply-To: <46D8470B.9030304@miralink.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Spam-Report: Spam detection software, running on the system "secure.socket.ch", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Sean Bruno wrote: > Tobias Roth wrote: >> Sean Bruno wrote: >> >>> I noticed that if rc.conf has ntpd_enable="NO", an invocation of >>> /etc/rc.d/ntpd stop won't actually shut down ntpd. I checked a couple >>> of other processes(like net-snmp) and noted the same behavior. >>> >>> I would have expected that rc would be able to invoke the stop routines >>> if a utility is disabled, but apparently the check for enabled/disabled >>> occurs much too early in the rc handling functions for the stop to fire >>> off. >>> I could investigate further, as I am sure that it's a fairly easy fix to >>> allow the stop functions to be invoked regardless of the enable/disable >>> state. Does it make sense to anyone else that the rc functions should >>> be able >>> to shutdown a process when it has been disabled in rc.conf? >>> >> >> /etc/rc.d/ntpd forcestop >> > Indeed one could invoke that. My question is more about what 'stop' > should or should not do. > > Specifically, should it 'stop' when a process has been disabled? [...] Content analysis details: (0.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 1.6 TVD_RCVD_IP TVD_RCVD_IP X-SA-Exim-Connect-IP: 80.219.162.83 X-SA-Exim-Mail-From: freebsd.lists@fsck.ch X-SA-Exim-Scanned: No (on secure.socket.ch); SAEximRunCond expanded to false Cc: freebsd-hackers@freebsd.org Subject: Re: rc functions don't allow processes to shutdown X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 17:38:03 -0000 Sean Bruno wrote: > Tobias Roth wrote: >> Sean Bruno wrote: >> >>> I noticed that if rc.conf has ntpd_enable="NO", an invocation of >>> /etc/rc.d/ntpd stop won't actually shut down ntpd. I checked a couple >>> of other processes(like net-snmp) and noted the same behavior. >>> >>> I would have expected that rc would be able to invoke the stop routines >>> if a utility is disabled, but apparently the check for enabled/disabled >>> occurs much too early in the rc handling functions for the stop to fire >>> off. >>> I could investigate further, as I am sure that it's a fairly easy fix to >>> allow the stop functions to be invoked regardless of the enable/disable >>> state. Does it make sense to anyone else that the rc functions should >>> be able >>> to shutdown a process when it has been disabled in rc.conf? >>> >> >> /etc/rc.d/ntpd forcestop >> > Indeed one could invoke that. My question is more about what 'stop' > should or should not do. > > Specifically, should it 'stop' when a process has been disabled? If 'stop' is the inverse of 'start', then no, as 'start' doesn't start a service if it is disabled. I agree that the naming could be improved to make it clear that 'start' and 'stop' both do their thing in respect of the setting in rc.conf, but I don't have an idea about how exactly to name them. Furthermore, using 'force' to do something without consideration of any ill effects and overriding any configuration is widely accepted. Because of this and in order to respect POLA, I'd just leave everything as it is. Cheers, Tobias