up vote 1 down vote favorite
share [g+] share [fb]

What happens when I issue sudo telinit n (n being the new runlevel)? Does init scans /etc/inittab and does exactly the same when system is booted? For example, if I have

rm:2345:wait:/etc/rc.multi

in my inittab, and I change runlevel from 5 to 3. Does /etc/rc.multi get re-executed or is it skipped?

link|improve this question
75% accept rate
feedback

1 Answer

up vote 2 down vote accepted

My understand of changing runlevels is that init "diffs" the old and new runlevel and starts / kills services whose status will changed.

In the given example, /etc/rc.multi would not be re-executed because it's already running. If you had rm:45:wait:/etc/rc.multi in your /etc/inittab, and went from runlevel 5 -> 3 -> 5, /etc/rc.multi would be killed (-> 3) and then started (-> 5) because it's not set for runlevel 3.

From the manpage:

When init is requested to change the runlevel, it sends the warning signal SIGTERM to all processes that are undefined in the new runlevel. It then waits 5 seconds before forcibly terminating these processes via the SIGKILL signal.

/etc/inittab is rescanned as you described:

After it has spawned all of the processes specified, init waits for one of its descendant processes to die, a powerfail signal, or until it is signaled by telinit to change the system's runlevel. When one of the above three conditions occurs, it re-examines the /etc/inittab file. New entries can be added to this file at any time. However, init still waits for one of the above three conditions to occur.

link|improve this answer
The manpage said "it sends the warning signal SIGTERM to all processes that are undefined in the new runlevel". What about the children of a process (let's say program /bin/foo) specified in inittab? My guess is that init treats the entire tree spawned by /bin/foo as a whole, but the manpage is confusing, and how do I prove my hypothesis? – xiaq Apr 28 '11 at 13:36
@xiaq: It says: "Note that init assumes that all these processes (and their descendants) remain in the same process group which init originally created for them. If any process changes its process group affiliation it will not receive these signals." So as long as the process group stays the same, it should kill those as well. To test it out, you could create a dummy application which forks a couple times, add it to inittab and try changing the runlevel to see if the children die as well. – BigChief Apr 28 '11 at 14:08
I'm sorry but what does "process group" mean? – xiaq Apr 29 '11 at 2:03
@xiaq: As described here, a process group is basically a way to distribute signals (such as SIGTERM) to a bunch of processes at once. By default all child processes will be in the group of their parent, and thus the cascading behavior when you send a SIGTERM/SIGKILL to the top-level process. In this case, this mechanism is how init is able to squash all the child processes of a service without explicitly keeping track of them. – BigChief Apr 29 '11 at 3:25
1  
@new123456: @xiaq didn't ask for the runlevel definitions, just the behavior of post-boot runlevel switching, so I don't see the need. And it looks like he knows them already. – BigChief Apr 30 '11 at 1:17
show 4 more comments
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.