Upstart: How does rc job work / order of (contradicting) "start on ..." and "stop on ..." stanzas
- by Binarus
Hi,
I just can't understand how Upstart's rc job definition in Natty 11.04 works. To illustrate the problem, here is the definition (empty lines and comments are left out):
start on runlevel [0123456]
stop on runlevel [!$RUNLEVEL]
export RUNLEVEL
export PREVLEVEL
console output
env INIT_VERBOSE
task
exec /etc/init.d/rc $RUNLEVEL
Let's suppose we currently are in runlevel 2 and the rc job is stopped (that is exactly the situation after booting my box and logging in via SSH). Now, let's assume that the system switches to runlevel 3, for example due to a command like "telinit 3" given by root. What will happen to the rc job?
Obviously, the rc job will be started since it is currently stopped and the event runlevel 3 is matching the start events. But from now on, things are unclear to me: According to the manual $RUNLEVEL evaluates to the new runlevel when the job is started (that means 3 in our example).
Therefore, the next stanza "stop on runlevel [!$RUNLEVEL]" translates to "stop on runlevel [!3]"; that means we have a first stanza which will trigger the job, but the second stanza will never stop the job and seems to be useless.
Since I know that the Ubuntu / Upstart people won't do useless things, I must be heavily misunderstanding something. I would be grateful for any explanation.
While trying to understand this, an additional question came to my mind. If I had contradicting start and stop triggers, for example
start on foo
stop on foo
what would happen? I swear I never will do that, but I am nevertheless very interested in how Upstart handles that on the theoretical level.
Thank you very much!
Editing the question as a reaction on geekosaur's first answer:
I can see the parallelism, but it is not that easy (at least, not to me).
Let's assume the job aurrently is still running, and a new runlevel event comes in (of course, the new runlevel is different from the current one). Then, the following should happen:
1) The job is single instance. That means that "start on ..." won't be triggered since the job is currently running; $RUNLEVEL is not touched.
2) "stop on ..." will be triggered since the new runlevel is different from $RUNLEVEL, so the job will be aborted.
3) Now, the job is stopped and waiting. I can't see how it is restarted with the new runlevel. AFAIK, initctl emits events only once, so "start on ..." won't be triggered and the new runlevel won't be entered.
I know that I still misunderstanding something, and I am grateful for explanations.
Thank you very much!
