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

Extending the update-rc.d API to change runlevel and disable scripts?

I believe we should extend the update-rc.d interface to provide a few
more operations that are commonly needed and commonly done wrong.

 - One operation to modify the runlevel used by a script/service.

 - One operation to disable a script and make sure it stay disabled.

The first operation will replace the remove-reinsert operation
currently being done in postinst script to change the runlevels, and
the second will make it easier for users to disable a service the
correct way.

I'm not sure what the optimal interface would be, but here is a draft:

Modify runlevels

At the moment this is done in some postinst scripts using for example

  update-rc.d -f script remove
  update-rc.d script defaults

This is actually the only way to do this currently with the provided
interface of update-rc.d.  The problem is that this drop any changes
done by the local sysadmin.  I propose a new operation to add or
remove runlevels, perhaps like this to drop the start symlink from
rcS.d and add it to rc2.d:

  update-rc.d script runlevel KS S2

This will rename any start symlinks in rcS.d/ to a stop symlink (and
do nothing if no symlink is present), and change any stop symlinks in
rc2.d/ to a start symlink (or add it if it isn't present).  Any better
suggestions on how to specify runlevel changes?  One issue to figure
out is how to handle static sequence number for start and stop.
Perhaps 'default' or start and stop sequence numbers need to be
provided as well.

Disable scripts

This has to be done manually or using one of the tools provided for
sysv-rc, and is different for earch boot system used.  I propose an
operation like

  update-rc.d script disable

It will rename all start symlinks to stop symlinks for all runlevels.
For dependency based boot sequencing, it will also update the sequence
numbers to reflect this new entry.

Any comments?  Better suggestions, objects, etc?

Happy hacking,
Petter Reinholdtsen

Reply to: