Date: Wed, 16 Jul 2008 13:45:01 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Dan Nelson <dnelson@allantgroup.com> Cc: freebsd-current@freebsd.org Subject: Re: Heads Up: shutdown keyword added to 34 rc.d scripts. Message-ID: <487E5DCD.3010206@FreeBSD.org> In-Reply-To: <20080716201819.GB19044@dan.emsphone.com> References: <487E533F.7050303@FreeBSD.org> <20080716201819.GB19044@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: > In the last episode (Jul 16), Doug Barton said: >> I've run with this locally for quite a while and just haven't had a >> chance to commit it. OTOH I don't use most of the stuff covered by >> this, so I'd like to get it tested in real world conditions for a >> while before it's MFC'ed. >> >> URL: http://svn.freebsd.org/changeset/base/180564 >> Log: >> ~ Add the shutdown KEYWORD to those scripts that start persistent >> ~ services to allow them to do a "clean" shutdown. >> >> ~ I purposely avoided making changes to network-related stuff since >> ~ the system shutting down is pretty conclusive, and there may be >> ~ complicated dependencies on the network that I would rather not try >> ~ to unravel. > > I think shutdown should be reserved for programs that save state > between instances or otherwise would cause a "cleanup" operation to run > then next time they are started after an unclean shutdown. That's not an unreasonable argument, however IMO it's better to be safe than sorry. > Adding > shutdown to things like amd, mountd, moused, etc. simply forces what > would be done in init's final SIGTERM sweep to be done sequentially > instead of in parallel. The ability to do things sequentially is a key benefit of the rc.d system. The fact that we have not been taking full advantage of that to date is (once again IMO) an oversight. > Also, if any of those daemons doesn't want to > immediately exit for some reason (amd hanging on a stuck mountpoint, > for example), it increases the likelyhood of the global shutdown timer > expiring and force-killing other daemons that might have wanted the > chance to shut down cleanly. That's a valid concern, which is why I want this to get real world testing before we consider MFC'ing it. As I said above, if this change causes real problems then those problems can easily be fixed. Doug -- This .signature sanitized for your protection
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?487E5DCD.3010206>