[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#317892: ITP: bum -- tool to manage boot scripts

On Tue, 12 Jul 2005 11:15:42 +0200, Federico Di Gregorio wrote:
> Boot-Up Manager is a graphical tool to allow easy configuration
> of init services in user and system runlevels, as far as changing
> Start/Stop services priority.

Consulting the documentation...
> 1.  Activate a de-activated script.
> BUM will create a standard S20<scriptname> symlink in directories
> related to runlevel 2,3,4 and 5 and will remove any
> Kxx<scriptname> symlink in the same directories. Further it
> creates K20<scriptname> in runlevel 0,1 and 6 directories. It
> also checks that the script "executable" and, if needed, will
> change it so that it is.
> 2. Deactivate an activated script.
> BUM will remove any Sxx<scriptname> symlink.

Very nice program, but the behavior described here is incorrect.
In order to deactivate the service, bum should install a
Kxx<scriptname> symlink.  Testing confirms that bum fails to do

Without a K symlink in the directory for the current runlevel,
when the service's package is upgraded, the service will be
started in the postinst even though it is configured to be

This issue has been discussed before and I believe that there is
a good consensus about it now.  Bum's current behavior leaves
deactivated services in a floating state and Debian does not
at present correctly support services left in the floating state.
(See #243159.)

You will need to choose an appropriate sequence number for the
K symlink.  I suggest: If there is a K symlink in another
directory then use its sequence number; otherwise use an old K
sequence number stored in database; otherwise use 100 minus
the S sequence number.  You may want to look at the source code
of sysv-rc-conf too.  Among the runlevel editors currently in
Debian it sucks the least.

Wishlist item: Grep the postinst files in order to obtain the
"factory default" sequence numbers and implement a "restore
factory default sequence numbers" feature.  See my last comment
in #183460.
Thomas Hood

Reply to: