#1554 A Debian user doesn't like this module

1.130
open
Jamie Cameron
5
2004-03-24
2004-03-23
Jaldhar H. Vyas
No

I received the following criticism of this module in the Debian
bug tracking system. What do you think?

Disabling service foo on boot seems to consist of deleting
/etc/rc?.d/S??foo. Enabling service foo on boot seems to
consist
of adding symlink S99foo to those of /etc/rc[235].d/ where
no
foo symlink is already present.

First of all, there is more to the runlevel system than
enabling and
disabling "at boot". Second, the way to disable a service in
a runlevel
is to rename its S symlink to a K symlink in that runlevel's
rc.d.
The way to enable a service in a runlevel is to rename its K
symlink to
an S symlink in that runlevel's rc.d. Appropriate sequence
numbers
should be used -- either the sequence number at which the
service was
originally installed or the last sequence number used for the
service
in that runlevel or the sequence number used for the service
in another
runlevel or 50 or the update-rc.d default 20. Where 99
comes from from
I don't know.

All the scripts run from rcS.d are listed as disabled at boot.
Switch
one on using the "Bootup and Shutdown" page and it gets
new S99 links
from rc2.d, rc3.d and rc5.d. Switch it off again and all its S
links
are deleted, including the one in rcS.d. That is totally
bogus.

Discussion

  • Jamie Cameron
    Jamie Cameron
    2004-03-24

    • status: open --> closed
     
  • Jamie Cameron
    Jamie Cameron
    2004-03-24

    Logged In: YES
    user_id=129364

    I suggest that this Debian user click on Module Config and
    change the 'Allow selection of individual runlevels?' option
    to 'Yes'. This will let him set the exact priorities and
    runlevels for each action, rather than using Webmin's
    inferred defaults.

     
  • Logged In: YES
    user_id=125881

    [I passed on your reply. Here is the response. Some of this I can
    probably change myself in the Debian package but there seem to
    be other more substantive issues]

    When I set

    Allow selection of individual runlevels?: Yes

    I see no difference in the appearance of the "Bootup and
    Shutdown"
    screen. When I additionally select:

    Display actions with descriptions: Yes, and show all runlevels

    then each service is displayed along with a list of runlevels in
    which it runs. The numeral '2' is displayed in red, presumably
    because the machine is currently running in runlevel 2.

    Another default needs to be changed:

    Runlevels to create new actions in: 2 3 4 5

    instead of "2 3 5".

    None of this addresses the fundamental problem, however, which
    is that services cannot be _disabled_ by deleting their S symlinks.
    Suppose you are in runlevel 2 with sendmail running. You delete
    sendmail's rc3.d/S symlink and then switch to runlevel 3. The
    service will _not_ be stopped. The absence of a symlink in a
    runlevel does not mean "disabled"; it means "floating". Debian
    doesn't correctly support services left in such a floating state:
    a service that is floating in the current runlevel will always
    be started if the package to which it belongs is upgraded even
    if it wasn't running before.

    What is worse, if you delete _all_ rc symlinks (as this webmin
    module does) then if the package is upgraded then the rc symlinks
    will all be reinstalled at their defaults. That is how
    update-rc.d works. (It works that way because the official way
    of disabling a service in a runlevel is to put a K symlink for
    it in that runlevel's rc directory. A total absence of symlinks
    is interpreted as the unconfigured state.)

    It also doesn't address the problem of 99 being chosen as the
    sequence number. The default should probably be S20 and K80.

     
    • status: closed --> open