From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0 Description of problem: After running "telinit u" UpStart jobs set to respawn that were in "start" change to "stop". eg the jobs tty1 -> tty6 will no longer respawn. This problem is made more serious by the fact that /etc/cron.daily/prelink will sometimes run "telinit u". As such init/UpStart no longer does a basic job of keeping certain processes running. Version-Release number of selected component (if applicable): upstart-0.3.9-19.fc9.i386 How reproducible: Always Steps to Reproduce: As root. 1. "initctl list" (to see jobs tty1 -> tty6 in "start" state) 2. "telinit u" 3. "tail /var/log/messages" to see that init has relaunched. 4. "initctl list" (jobs tty1 -> tty6 now in "stop" state) 5. login/logout of tty1 to end the tty1 process -- no login prompt will reappear as the tty1 job is not restarted. Actual Results: tty1 -> tty6 will not be restarted once they exit. Expected Results: UpStart jobs in the "start" state need to remain in the "start" state after "telinit u". Alternatively tty1 -> tty6 need UpStart "start on" parameters that will see them restarted after init is relaunched. Additional info:
This explains a LOT of other issues we've had. I'm going to go mark some duplicates, then I'll get with Scott about a fix.
*** Bug 446018 has been marked as a duplicate of this bug. ***
*** Bug 451504 has been marked as a duplicate of this bug. ***
Its been a couple of months since anything appeared on this bug report by the looks of it, how are things progressing on getting it resolved? I have this same problem on my Fedora 9 system.
The upstart codebase has been kind of a moving target, so we've not been able to pin down a solution. We'll look at solving this once we get 0.5.0 running smoothly.
same problem in Fedora 10
I can confirm that this problem still exists in Fedora 10. Also I think bug #472925 is, for the main part, a duplicate of this bug.
*** Bug 472925 has been marked as a duplicate of this bug. ***
*** Bug 478427 has been marked as a duplicate of this bug. ***
This really needs to be fixed. If I login at the console (tty), and subsequent logout causes the tty be lost. This has been described many times elsewhere. That would seem to be a serious problem. And yes, this problem seems to have first appeared in Fedora 9 and is still occurring in Fedora 10.
Its a serious bug while the symptoms persist, but as you might surmise, rebooting resolves the issue. It only gets tripped again during certain updates. Most people never observe it twice.
Rebooting is not a practical solution. The bug is annoying and I ran into it on a significant number of occasions whilst using FC9. I got tired of waiting for it to be fixed so that I blew FC9 away and installed FreeBSD instead.
Perhaps until this issue is fixed the 'telinit u' lines should be removed from /etc/cron.daily/prelink and anywhere else it is called.
prelink calls 'telinit u' whenever the init binary or libc.so.6 have changed. What does it need to do that for?
To make sure that the latest init binary is always loaded and always linked against the most recent libc. We've decided to simply disable telinit u until there's a good solution for this. Fix forthcoming.
(In reply to comment #15) > To make sure that the latest init binary is always loaded and always linked > against the most recent libc. post-install scripts don't do that?
I think they do (by the same mechanism, so it doesn't avoid the bug). I guess its supposed to protect against home-built libc scenarios? It wasn't my call at any rate :)
(In reply to comment #15) > To make sure that the latest init binary is always loaded and always linked > against the most recent libc. > > We've decided to simply disable telinit u until there's a good solution for > this. Fix forthcoming. Hmm. I assume that you're referring to the last line of the /etc/cron.daily/prelink. So without the 'telinit u', prelinking will still be done but init will not be restarted. The way I understood this (perhaps incorrectly) was that an update could occur that changed libc. Eventually, the daily prelink cron job would detect this and cause the 'telinit u', which resulted in ttys being in stop state. That would explain why it is possible to do an yum update, reboot, and still hit this -- because the prelink had not been done. So the fallout is that whenever libc changes, the ttys are fine until the prelink cron job is run. After that, you should be able to reboot the machine and no longer hit this problem ... at least until libc changes again. Please correct me if I am wrong. I looked at the tty[1-6] files in /etc/event.d and nothing jumped out at me. I don't see why the ttys get stopped on 'telinit u'.
The following patch fixes the problem for us on upstart-0.3.9 by having init pass state information (the goal, state, and associated process ids) to its successor when re-execing itself. Testing and comments are welcome.
Created attachment 329868 [details] Patch to allow upstart to preserve job information when re-execing itself
Just from a quick run-through, its a bit stylistically inconsistent with the rest of the codebase. But I'm happy to try the patch.
Just pushed patched to Bodhi. The formatting is a bit off, but we can worry about that if upstream takes it. The people following this have waited long enough ;) Bug will close when the updates pass testing.
Thanks! I didn't worry too much about the formatting for this version of the patch because I figured it would need considerable reworking anyway to go upstream, (since upstream is several versions ahead and seems to have significant differences in its event/job structures). Instead I wanted to use a style that made it easy for me to see as much of the logic as possible per screen, since messing with init is something I wanted to be really careful with and I find I personally am more prone to make mistakes when writing in a less compact style. If it tests well and is working and nobody finds any bugs, I figured that would at least allow Fedora 10 users like us to have a working init and then whoever does the work of adapting it to the upstream version could reformat it as appropriate.
upstart-0.3.9-22.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update upstart'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1035
upstart-0.3.9-22.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing-newkey update upstart'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-1047
upstart-0.3.9-22.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
upstart-0.3.9-22.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.