Improving halt package interaction...
Thomas M Steenholdt
tmus at tmus.dk
Fri Nov 16 00:55:36 UTC 2007
Thomas M Steenholdt wrote:
> Hi all...
>
> I'd like to bring up a suggestion that would make it easier for
> packagers to modify the halt process, without resorting to changing
> files owned by other packages.
>
> Currently /etc/init.d/halt provides a hook into the halt process via an
> /sbin/halt.local file. If this file exists and is executable, it will be
> run during the halt process. This makes it possible for system
> administrators to write their own halt modifier (typically needed when
> dealing with UPSes and possibly other types of packages).
>
> I think it would be very valuable to extend this functionality of
> /etc/init.d/halt to support a /etc/halt.d/ directory in addition to the
> halt.local script (Why is halt.local currently not located in /etc along
> with rc.local and such but in /sbin btw?). This would allow a package
> (an UPS software package as an example) to drop a halt modifier script
> in /etc/halt.d/ to take care of prepping the system for halt (rather
> that poweroff) and initiate a delayed UPS poweroff, if a mains powerloss
> condition was detected. Currently the package will have to hack either
> /sbin/halt.local, which could be difficult, or /etc/init.d/halt which
> would be just plain bad. Usually they will simply leave this out and the
> system admin will have to set it up manually, for the UPS to work properly.
>
> The current version of the /etc/init.d/halt script (from
> initscripts-8.60-1) includes UPS handling code for the NUT UPS
> software(i think). NUT could easily be made to use the new /etc/halt.d/
> infrastructure too, and /etc/init.d/halt could get rid of the
> non-generic UPS handling code, which IMHO should be avoided anyway...
>
> What do you guys think about this?
>
> /Thomas
>
I've created a bug to make it easier to track. If this could be of
interest, I'd be happy to supply an appropriate patch.
https://bugzilla.redhat.com/show_bug.cgi?id=386071
/Thomas
More information about the fedora-devel-list
mailing list