Re: /etc/init.d/ - add/remove services
In article <[🔎] 1075583446.1859.2697.camel@thanatos.hubertnet>,
Thomas Hood <jdthood@yahoo.co.uk> wrote:
>Note that the expectation of the System V init system is
>that every service have either an S or a K symlink in each
>runlevel. If there is no symlink for a service in a particular
>runlevel then the behavior of sysv's invoke-rc.d is undefined
>for that service in that runlevel. Methods of shutting off
>services must take that into account.
>
>Suppose you have service foo that is S20 in runlevel 2 and
>you want to shut it off. You should do something like:
>
> /etc/rc2.d/$ mv S20foo K80foo_originallyS20
>
>As someone has already pointed out, update-rc.d is intended for
>use by maintainer scripts. It allows maintainer scripts to
>work independently of which init system is in use, whether it
>is the System V init system, file-rc or some other. The
>local administrator need not use update-rc.d to change sysv
>symlinks.
A thought just hit me.
What if we added a "update-rc.d <name> enable|disable" command?
That has never been done because the implementation would
be awkward and wouldn't fit into the sysv-rc design.
But what if we used the destination of the symlink ?
The "disable" command would simply walk over all symlinks in
/etc/rc?.d of the form ^S\d+name$ and point them to
/bin/true.
The "enable" command would do the reverse, point the symlinks
back to /etc/init.d/name.
That would keep the essence of any local config, and would
make it trivial to switch services on and off. Anyone
looking at it would also intuitively understand what
was going on.
Ofcourse invoke-rc.d should know about this, and file-rc needs
to be updated (it can easily store this state in its
config file I think) but otherwise implementation should
be trivial.
Only thing is - should the links of the disabled service
point to /bin/true or to some special, non-existing location
that is easy to detect with test -e ? Or perhaps use /dev/null,
which is detectable with test -e file && ! test -s file ?
I see that currently /bin/true is a small ELF binary,
not a shell script anymore, so it would't be too much
overhead to run it.
Mike.
Reply to: