Professional Web Applications Themes

Why does /etc/rc.d/rc work the way it does? - Linux Setup, Configuration & Administration

I'll admit straight away to being primarily a Windows user (sorry, should I term it "Windoze"?), so please go easy on me this one time. And perhaps this will give you a little understanding of my relative ineptitude. I installed RedHat 9 and got it working just fine. I'm working through the RH9 Bible [Negus] and am currently on the section regarding System Start-Up and Shutdown, run-level scripts specifically. I am looking at the text of /etc/rc.d/rc and I cannot understand why it does what it does. From what I can tell, the script is called with an argument indicating ...

  1. #1

    Default Why does /etc/rc.d/rc work the way it does?

    I'll admit straight away to being primarily a Windows user (sorry,
    should I term it "Windoze"?), so please go easy on me this one time.
    And perhaps this will give you a little understanding of my relative
    ineptitude.

    I installed RedHat 9 and got it working just fine. I'm working
    through the RH9 Bible [Negus] and am currently on the section
    regarding System Start-Up and Shutdown, run-level scripts
    specifically. I am looking at the text of /etc/rc.d/rc and I cannot
    understand why it does what it does. From what I can tell, the script
    is called with an argument indicating to which run-level the OS should
    change. Given this, the script is supposed to kill run-level scripts
    from the current level and then start scripts from the new level. As
    I understand the script, here are the steps, very much distilled:

    1. Get the argument to the script, place it in argv1
    2. Get the current and previous run-levels, run-level and previous,
    respectively.
    3. Choose whether to enter interactive or non-i mode.
    4. *** Assign argv1 to run-level.
    5. Run the kill scripts for run-level (which is now set to the new,
    desired level!)
    6. Run the start scripts for run-level

    It seems like step 2 should come after step 5. I must be missing
    something. Can someone enlighten me?

    --
    Thanks,
    Chris Simmons
    org

    *** IMPORTANT - DO NOT REPLY TO ABOVE E-MAIL ADDRESS ***
    It exists solely as bait for spam. If you wish to e-mail
    me (and have me actually READ your e-mail), use the address
    listed in the From: header.
    Chris Guest

  2. #2

    Default Re: Why does /etc/rc.d/rc work the way it does?

    Chris Simmons wrote:
     

    No, it runs both the kill scripts and start scripts from the new level.

    --
    Markku Kolkka
    fi
    Markku Guest

  3. #3

    Default Re: Why does /etc/rc.d/rc work the way it does?

    On Mon, 19 Jan 2004 14:07:01 +0200, Markku Kolkka
    <fi> wrote:
     
    >
    >No, it runs both the kill scripts and start scripts from the new level.[/ref]

    So, assuming this, if I was to start out at, say, runlevel 2, then go
    to 3, then to 4, I will have all the services from 2, 3, and 4 all
    started?

    --
    Thanks,
    Chris Simmons
    org

    *** IMPORTANT - DO NOT REPLY TO ABOVE E-MAIL ADDRESS ***
    It exists solely as bait for spam. If you wish to e-mail
    me (and have me actually READ your e-mail), use the address
    listed in the From: header.
    Chris Guest

  4. #4

    Default Re: Why does /etc/rc.d/rc work the way it does?

    On Mon, 19 Jan 2004 21:09:26 -0500, Chris Simmons wrote: 

    No, services are killed, then started, try

    chkconfig --list
    or look at
    ls /etc/rc.d/rc2.d > /tmp/l2
    ls /etc/rc.d/rc3.d > /tmp/l3
    ls /etc/rc.d/rc4.d > /tmp/l4

    diff /tmp/l2 /tmp/l3
    diff /tmp/l4 /tmp/l4

    Bit Guest

  5. #5

    Default Re: Why does /etc/rc.d/rc work the way it does?

    On Mon, 19 Jan 2004 14:07:01 +0200, Markku Kolkka <fi> wrote: 
    >
    > No, it runs both the kill scripts and start scripts from the new level.[/ref]

    I doubt it. How would kill scripts in the new level know what to kill in
    the old level. For example level 3 has networking and level 2 does not.
    So if you changed from 3 to 2 how would level 2 scripts know how to kill
    networking if it has no networking? So it must run the current level kill
    scripts (which knows what to kill in what order) and then the new level
    start scripts.

    --
    David Efflandt - All spam ignored http://www.de-srv.com/
    David Guest

  6. #6

    Default Re: Why does /etc/rc.d/rc work the way it does?

    David Efflandt writes: 

    I don't think you understand what the 'kill scripts' are. They are just
    symlinks to scripts in /etc/init.d. Links that start with 'K' ('kill'
    links) are called with the argument 'stop' while links that start with 'S'
    are called with the argument 'start'. There is one script in /etc/init.d
    for each service with 'K' and 'S' links sprinkled around the rc.d
    directories appropriately.


    From /usr/share/doc/sysvinit/README.runlevels:

    1. Boot.

    When the systems boots, the /etc/init.d/rcS script is executed. It
    in turn executes all the S* scripts in /etc/rcS.d in alphabetical
    (and thus numerical) order. The first argument passed to the
    executed scripts is "start". The runlevel at this point is "N" (none).

    Only things that need to be run once to get the system in a consistent
    state are to be run. The rcS.d directory is NOT meant to replace rc.local.
    One should not start daemons in this runlevel unless absolutely
    necessary. Eg, NFS might need the portmapper, so it is OK to start it
    early in the bootprocess. But this is not the time to start the
    squid proxy server.

    2. Going multiuser.

    After the rcS.d scripts have been executed, init switches to the
    default runlevel as specified in /etc/inittab, usually "2".

    Init then executes the /etc/init.d/rc script which takes care of
    starting the services in /etc/rc2.d.

    Because the previous runlevel is "N" (none) the /etc/rc2.d/K
    scripts will NOT be executed - there is nothing to stop yet,
    the system is busy coming up.

    If for example there is a service that wants to run in runlevel 4
    and ONLY in that level, it will place a K script in
    /etc/rc{2,3,5}.d to stop the service when switching out of runlevel 4.
    We do not need to run that script at this point.

    The /etc.rc2.d/S scripts will be executed in alphabetical
    order, with the first argument set to "start".

    3. Switching runlevels.

    When one switches from (for example) runlevel 2 to runlevel 3,
    /etc/init.d/rc will first execute in alphabetical order all K
    scripts for runlevel 3 (/etc/rc3.d/K) with as first argument
    "stop" and then all S scripts for runlevel 3 (/etc/rc3.d/S)
    with as first argument "start".

    As an optimization, a check is made for each "service" to see if
    it was already running in the previous runlevel. If it was, and there
    is no K (stop) script present for it in the new runlevel, there is
    no need to start it a second time so that will not be done.

    On the other hand, if there was a K script present, it is assumed the
    service was stopped on purpose first and so needs to be restarted.


    --
    John Hasler
    gt.org
    Dancing Horse Hill
    Elmwood, Wisconsin
    John Guest

  7. #7

    Default Re: Why does /etc/rc.d/rc work the way it does?

    On Tue, 20 Jan 2004 03:29:06 +0000 (UTC), com (David
    Efflandt) wrote:
     
    >>
    >> No, it runs both the kill scripts and start scripts from the new level.[/ref]
    >
    >I doubt it. How would kill scripts in the new level know what to kill in
    >the old level. For example level 3 has networking and level 2 does not.
    >So if you changed from 3 to 2 how would level 2 scripts know how to kill
    >networking if it has no networking? So it must run the current level kill
    >scripts (which knows what to kill in what order) and then the new level
    >start scripts.[/ref]

    This is what I thought *should* happen, but the /etc/rc.d/rc script
    seems to want to kill the scripts from the new level, then start the
    same scripts. I would think this would leave services from the old
    level started.
    --
    Thanks,
    Chris Simmons
    org

    *** IMPORTANT - DO NOT REPLY TO ABOVE E-MAIL ADDRESS ***
    It exists solely as bait for spam. If you wish to e-mail
    me (and have me actually READ your e-mail), use the address
    listed in the From: header.
    Chris Guest

  8. #8

    Default Re: Why does /etc/rc.d/rc work the way it does?

    On Tue, 20 Jan 2004 03:29:06 +0000 (UTC), David Efflandt wrote: 

    When you run telinit 2 from level 3, level 3 Kills are executed and
    level 2 Starts are executed.

    On my Mandrake box, the display manager (dm) has a kill but not start
    in level 3 and in 5 I have a kill and a start for dm.
    Bit Guest

  9. #9

    Default Re: Why does /etc/rc.d/rc work the way it does?

    John Hasler <gt.org> wrote: 
    >
    > I don't think you understand what the 'kill scripts' are. They are just[/ref]

    Nevertheless, he is logically correct. You cannot put in each runlevel
    a list of all the processes that must be killed if he is coming from an
    arbitrary other runlevel. Only the other runlevel knows what should be
    killed as you leave it.

     
     

    That is a mistaken idea. Strange. Michaels understands finite state
    automata!

     

    I.e. they attempt to fix the brokenness. What they should do is check
    if there is a S script in OLD runlevel and S script in new, and no
    restart in that case.
     

    I see. So the absence of a stop script in the NEW runlevel means that
    it should not be stopped (before being started :-).
     

    But the presence of a K script in the NEW runlevel means that it should
    be STARTED. Tell me that that is logical.

    Peter
    P.T. Guest

  10. #10

    Default Re: Why does /etc/rc.d/rc work the way it does?

    On Tue, 20 Jan 2004 04:34:32 GMT, Bit Twister
    <localdomain> wrote:
     

    If you use Red Hat and the chkconfig utility, it places kill links for
    a service in every run level where that service is not supposed to run
    and start links in every level where that service is supposed to run.

    The UNIX System Administration handbook says this:

    When init transitions from a lower run level to a higher one, it runs
    all the scripts that start with S in ascending numerical order with
    the argument start. When init transitions from a higher run level to
    a lower one, it runs all the scripts that start with K (for "kill") in
    descending numerical order with the argument stop. Depending on the
    system, init may look only at the rclevel.d directory appropriate for
    the new run level, or it may look at every rclevel.d directory between
    the current run level and the new run level.


    --
    Richard Steven Hack
    "Whatever does not kill me makes me stronger" -
    and YOU have not killed me!
    Richard Guest

  11. #11

    Default Re: Why does /etc/rc.d/rc work the way it does?

    Chris Simmons writes: 

    Conceptually all the kill links in the new level are executed followed by
    all the start scripts. As an optimization the Debian rc script doesn't
    run start links for services that were running in the previous level and
    weren't stopped in the new one. In most cases it is silly for a service to
    have both kill and start links in the same level.
    --
    John Hasler
    gt.org
    Dancing Horse Hill
    Elmwood, Wisconsin
    John Guest

  12. #12

    Default Re: Why does /etc/rc.d/rc work the way it does?

    Chris Simmons <com> writes:

    ]I'll admit straight away to being primarily a Windows user (sorry,
    ]should I term it "Windoze"?), so please go easy on me this one time.
    ]And perhaps this will give you a little understanding of my relative
    ]ineptitude.

    ]I installed RedHat 9 and got it working just fine. I'm working
    ]through the RH9 Bible [Negus] and am currently on the section
    ]regarding System Start-Up and Shutdown, run-level scripts
    ]specifically. I am looking at the text of /etc/rc.d/rc and I cannot
    ]understand why it does what it does. From what I can tell, the script
    ]is called with an argument indicating to which run-level the OS should
    ]change. Given this, the script is supposed to kill run-level scripts
    ]from the current level and then start scripts from the new level. As
    ]I understand the script, here are the steps, very much distilled:

    ]1. Get the argument to the script, place it in argv1
    ]2. Get the current and previous run-levels, run-level and previous,
    ]respectively.
    ]3. Choose whether to enter interactive or non-i mode.
    ]4. *** Assign argv1 to run-level.
    ]5. Run the kill scripts for run-level (which is now set to the new,
    ]desired level!)
    ]6. Run the start scripts for run-level

    ]It seems like step 2 should come after step 5. I must be missing

    No. The Kill scripts in the new run level indicte that those programs
    should NOT be running in that runlevel. Ie, it is the new runlevel's
    kill scripts that should be run, as well as the new runlevel's start
    scripts. The kill scripts mean "make sure that this service in not
    running in this run level".



    ]something. Can someone enlighten me?

    ]--
    ]Thanks,
    ]Chris Simmons
    ]org

    ]*** IMPORTANT - DO NOT REPLY TO ABOVE E-MAIL ADDRESS ***
    ]It exists solely as bait for spam. If you wish to e-mail
    ]me (and have me actually READ your e-mail), use the address
    ]listed in the From: header.
    Bill Guest

  13. #13

    Default Re: Why does /etc/rc.d/rc work the way it does?

    com (David Efflandt) writes:

    ]On Mon, 19 Jan 2004 14:07:01 +0200, Markku Kolkka <fi> wrote:
    ]> Chris Simmons wrote:
    ]>
    ]>> Given this, the script is supposed to kill run-level scripts
    ]>> from the current level and then start scripts from the new level.
    ]>
    ]> No, it runs both the kill scripts and start scripts from the new level.

    ]I doubt it. How would kill scripts in the new level know what to kill in
    ]the old level. For example level 3 has networking and level 2 does not.
    ]So if you changed from 3 to 2 how would level 2 scripts know how to kill
    ]networking if it has no networking? So it must run the current level kill
    ]scripts (which knows what to kill in what order) and then the new level
    ]start scripts.

    The scripts themselves are all in /etc/init.d. The stuff in the rc?.d
    are all links. Thus, the script to kill or start networking is available
    in all runlevels. If you have the K??networking in runlevel 2, that
    means
    "run the script
    /etc/init.d/networking stop
    "
    which will kill the networking if it is running. If it is not running,
    no harm done.



    Bill Guest

  14. #14

    Default Re: Why does /etc/rc.d/rc work the way it does?

    it.uc3m.es (P.T. Breuer) writes:


    ]Nevertheless, he is logically correct. You cannot put in each runlevel
    ]a list of all the processes that must be killed if he is coming from an
    ]arbitrary other runlevel. Only the other runlevel knows what should be
    ]killed as you leave it.

    No. You put in K links for all of those processes in /etc/init.d for
    which you do NOT want them running in that runlevel. You put in S links
    for those you want running, and nothing for those you do not care if
    they run or not.



    ]> From /usr/share/doc/sysvinit/README.runlevels:

    ]> 3. Switching runlevels.
    ]>
    ]> When one switches from (for example) runlevel 2 to runlevel 3,
    ]> /etc/init.d/rc will first execute in alphabetical order all K
    ]> scripts for runlevel 3 (/etc/rc3.d/K) with as first argument
    ]> "stop" and then all S scripts for runlevel 3 (/etc/rc3.d/S)
    ]> with as first argument "start".

    ]That is a mistaken idea. Strange. Michaels understands finite state
    ]automata!

    Why is that a mistaken idea?



    ]> As an optimization, a check is made for each "service" to see if
    ]> it was already running in the previous runlevel. If it was, and there

    ]I.e. they attempt to fix the brokenness. What they should do is check
    ]if there is a S script in OLD runlevel and S script in new, and no
    ]restart in that case.

    That is what they do. But IF you have both a K and an S for that service
    in this runlevel, it obviously means you want it killed first.


    ]> is no K (stop) script present for it in the new runlevel, there is
    ]> no need to start it a second time so that will not be done.

    ]I see. So the absence of a stop script in the NEW runlevel means that
    ]it should not be stopped (before being started :-).

    Yes, no K means do not stop it. (what has starting got to do with it?
    You start something only if it has an S link, and you do NOT put in both
    a K link and an S link to the same thing. That is silly in general.
    There might be some cases in which the script behaves differently in
    different run levels and in which both a K and and S in the same
    runlevel makes sense, but I do not know of any.)


    ]> On the other hand, if there was a K script present, it is assumed the
    ]> service was stopped on purpose first and so needs to be restarted.

    ]But the presence of a K script in the NEW runlevel means that it should
    ]be STARTED. Tell me that that is logical.

    How do you deduce that? K always means stop. Always.


    You should put in rc?.d K links for all programs which you do NOT want
    running in that runlevel. YOu put S scripts for all programs you want
    running, and you put nothing for all programs in /etc/init.d that you do
    not care about.


    Bill Guest

  15. #15

    Default Re: Why does /etc/rc.d/rc work the way it does?

    Bill Unruh <physics.ubc.ca> wrote: 

    That would imply that whenever you install a new daemon, you would have
    to install K links for it by default in every possible run level, and
    then remove the links for only the runlevels in which you don't want it
    killed.
     

    You don't even KNOW what run levels there are, speaking as a program
    developer (so you don't know if you care or not). And the packager
    doesn't know what run levels the user has defined either. So this
    places a huge burden on the admin - he has to add K's everywhere
    by default, except the places where they _deliberately_ (not
    accidentally) do not appear in the package. And how can he distinguish
    absence by intent from absence by accident?
     

    Because it is stateless, in a system that is fundamentally a state
    machine. There are usually something like 5 states, S 1 2 3 0 6.
    The transitions are S <-> 1 <-> 2 <-> 3 <-> 0|6, in principle (and
    maybe more). In a state machine it is the transitions that carry
    actions - i.e. coming from 3 to 0 is different to coming from 2 to 0.
    If the action is always dependent only on the target, not the place you
    came from too, then the action is stateless, without memory, without
    history, and you have a non-state state machine. Which is silly.


     

    Intuitively, it means to me that I want it killed on leaving this run
    level, unless there is an S in the next run level too. That is the
    natural way to say that I want this to work in this run level but not
    by default in any other, unless the designer of the other run level
    wants it there too.
     

    So you put an S where you definitely want things to run, and a K where
    you definitely want them to stop. But putting in a K everywhere does no
    harm, because at worst it makes the service be stopped then restarted.

    Hmm.
     

    Because if there is a K and an S, then the service is stopped, then
    started. In the absence of a K (bt presence of an S), it is not stopped
    and therefore not started, as I understand you.
     

    That is the problem. As admin, you don't know what programs you don't
    want ahead of installing them, and as packager, you don't know what
    runlevels the admin has set up.
     

    But you don't know which programs you do not care about, and the
    packager cannot help you (by installing K's by default) because he
    does not know what runlevels you have.

    It makes far more sense for the packager to confine himself to
    configuring those runlevels for which notionally he is the designer.

    Peter
    P.T. Guest

  16. #16

    Default Re: Why does /etc/rc.d/rc work the way it does?

    I wrote: 

    P.T. Breuer writes: 

    He's implying that he thinks that the links are scripts and they need to
    know "what to kill and in what order".
     

    Of course you can. It's just a list of all the processes that are not to
    run in the new level.
     

    Nothing.
     

    That is how Linux has always done it.
     

    What brokenness? If there was an S link in the previous level for the
    subject initscript then the service must either already be running or have
    been stopped by the admin. In neither case it should be started.
     

    That is what they do.
     

    The presence of both a K and an S link means that the service should be
    stopped and then started. I can think of no good reason why you would want
    to configure a service that way, but the case is handled so you can do it
    if you want to.
    --
    John Hasler
    gt.org
    Dancing Horse Hill
    Elmwood, Wisconsin
    John Guest

  17. #17

    Default Re: Why does /etc/rc.d/rc work the way it does?

    Richard Steven Hack writes: 

    Linux does not use the Sys V "layering" system.
    --
    John Hasler
    gt.org
    Dancing Horse Hill
    Elmwood, Wisconsin
    John Guest

  18. #18

    Default Re: Why does /etc/rc.d/rc work the way it does?

    Peter writes: 

    No. It will be started unless there was an S link it the previous level.
    In that case it is assumed that it is either still running or was stopped
    by the admin.
     

    The default configuration in Debian is to put K links in 0 and 6 and S
    links in 1-5.
    --
    John Hasler
    gt.org
    Dancing Horse Hill
    Elmwood, Wisconsin
    John Guest

  19. #19

    Default Re: Why does /etc/rc.d/rc work the way it does?

    it.uc3m.es (P.T. Breuer) writes:

    ]Bill Unruh <physics.ubc.ca> wrote:
    ]> it.uc3m.es (P.T. Breuer) writes:
    ]>
    ]>
    ]> ]Nevertheless, he is logically correct. You cannot put in each runlevel
    ]> ]a list of all the processes that must be killed if he is coming from an
    ]> ]arbitrary other runlevel. Only the other runlevel knows what should be
    ]> ]killed as you leave it.
    ]>
    ]> No. You put in K links for all of those processes in /etc/init.d for
    ]> which you do NOT want them running in that runlevel.

    ]That would imply that whenever you install a new daemon, you would have
    ]to install K links for it by default in every possible run level, and
    ]then remove the links for only the runlevels in which you don't want it
    ]killed.

    Only if it was important that the service not run in that runlevel. Eg,
    xdm should not run in runlevel 3, so put the K??xdm in runlevel 123.


    ]> You put in S links
    ]> for those you want running, and nothing for those you do not care if
    ]> they run or not.

    ]You don't even KNOW what run levels there are, speaking as a program
    ]developer (so you don't know if you care or not). And the packager
    ]doesn't know what run levels the user has defined either. So this
    ]places a huge burden on the admin - he has to add K's everywhere
    ]by default, except the places where they _deliberately_ (not
    ]accidentally) do not appear in the package. And how can he distinguish
    ]absence by intent from absence by accident?

    ??????? Runlevels are not defined by the user. They are defined by the
    system.
    And if the user wants to define runlevels, the user can figure out which
    services he/she wants on the runlevel. What's the problem?


    ]> ]> 3. Switching runlevels.
    ]> ]>
    ]> ]> When one switches from (for example) runlevel 2 to runlevel 3,
    ]> ]> /etc/init.d/rc will first execute in alphabetical order all K
    ]> ]> scripts for runlevel 3 (/etc/rc3.d/K) with as first argument
    ]> ]> "stop" and then all S scripts for runlevel 3 (/etc/rc3.d/S)
    ]> ]> with as first argument "start".
    ]>
    ]> ]That is a mistaken idea. Strange. Michaels understands finite state
    ]> ]automata!
    ]>
    ]> Why is that a mistaken idea?

    ]Because it is stateless, in a system that is fundamentally a state
    ]machine. There are usually something like 5 states, S 1 2 3 0 6.
    ]The transitions are S <-> 1 <-> 2 <-> 3 <-> 0|6, in principle (and
    ]maybe more). In a state machine it is the transitions that carry
    ]actions - i.e. coming from 3 to 0 is different to coming from 2 to 0.
    ]If the action is always dependent only on the target, not the place you
    ]came from too, then the action is stateless, without memory, without
    ]history, and you have a non-state state machine. Which is silly.


    ???? Each runlevel has certain services you want to run and certain you
    do not. The runlevel defines the state. The only memory you want is to
    know what the current runlevel is. The state is defined by the services
    you want running at that level, and if you do not care if a service is
    running or not, then you do not care.



    ]> ]> As an optimization, a check is made for each "service" to see if
    ]> ]> it was already running in the previous runlevel. If it was, and there
    ]>
    ]> ]I.e. they attempt to fix the brokenness. What they should do is check
    ]> ]if there is a S script in OLD runlevel and S script in new, and no
    ]> ]restart in that case.
    ]>
    ]> That is what they do. But IF you have both a K and an S for that service
    ]> in this runlevel, it obviously means you want it killed first.

    ]Intuitively, it means to me that I want it killed on leaving this run
    ]level, unless there is an S in the next run level too. That is the
    ]natural way to say that I want this to work in this run level but not
    ]by default in any other, unless the designer of the other run level
    ]wants it there too.

    Well, I guess you could set up a way of doing that-- the rc files are
    there for you to play with. However this is NOT the model that Linux
    uses. You could sell a new system called PBux if you want with your
    style. It is the level that decides on the service not the service that
    decides on the levels it wants to on.


    ]> ]> is no K (stop) script present for it in the new runlevel, there is
    ]> ]> no need to start it a second time so that will not be done.
    ]>
    ]> ]I see. So the absence of a stop script in the NEW runlevel means that
    ]> ]it should not be stopped (before being started :-).
    ]>
    ]> Yes, no K means do not stop it. (what has starting got to do with it?
    ]> You start something only if it has an S link, and you do NOT put in both
    ]> a K link and an S link to the same thing. That is silly in general.
    ]> There might be some cases in which the script behaves differently in
    ]> different run levels and in which both a K and and S in the same
    ]> runlevel makes sense, but I do not know of any.)

    ]So you put an S where you definitely want things to run, and a K where
    ]you definitely want them to stop. But putting in a K everywhere does no
    ]harm, because at worst it makes the service be stopped then restarted.

    ]Hmm.

    ]> ]> On the other hand, if there was a K script present, it is assumed the
    ]> ]> service was stopped on purpose first and so needs to be restarted.
    ]>
    ]> ]But the presence of a K script in the NEW runlevel means that it should
    ]> ]be STARTED. Tell me that that is logical.
    ]>
    ]> How do you deduce that? K always means stop. Always.

    ]Because if there is a K and an S, then the service is stopped, then
    ]started. In the absence of a K (bt presence of an S), it is not stopped
    ]and therefore not started, as I understand you.

    ]> You should put in rc?.d K links for all programs which you do NOT want

    ]That is the problem. As admin, you don't know what programs you don't
    ]want ahead of installing them, and as packager, you don't know what
    ]runlevels the admin has set up.

    ]> running in that runlevel. YOu put S scripts for all programs you want
    ]> running, and you put nothing for all programs in /etc/init.d that you do
    ]> not care about.

    ]But you don't know which programs you do not care about, and the
    ]packager cannot help you (by installing K's by default) because he
    ]does not know what runlevels you have.

    ]It makes far more sense for the packager to confine himself to
    ]configuring those runlevels for which notionally he is the designer.

    T

    ]Peter

    Bill Guest

  20. #20

    Default Re: Why does /etc/rc.d/rc work the way it does?

    John Hasler <gt.org> wrote: 
    >
    > No. It will be started unless there was an S link it the previous level.
    > In that case it is assumed that it is either still running or was stopped
    > by the admin.[/ref]

    It may have died of natural causes (oom killer, nfs lockd with no recent
    clients, etc). So the absence of a K means that the service is not
    (re)started when entering the new run level, even though the reason
    for entering the new run level may be in order to start the services
    expected to run at that level.
     
    >
    > The default configuration in Debian is to put K links in 0 and 6 and S
    > links in 1-5.[/ref]

    I hadn't noticed. A quick "locate .d/K" shows them in 0 1 and 6.

    Peter
    P.T. Guest

Page 1 of 2 12 LastLast

Similar Threads

  1. Links don't work in Shockwave movie but work in p
    By rokarege in forum Macromedia Director Basics
    Replies: 1
    Last Post: May 3rd, 02:02 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139