Description of problem: Following upgrade (using yum) from Fedora 12 to Fedora 13 pre-beta, system cannot be shut down using /sbin/shutdown, nor change runlevels with /sbin/init. # /sbin/init 1 init: Failed to connect to socket /com/ubuntu/upstart: Connection refused No other shutdown or restart methods have been successful, short of the ACPI 5-second power button hard power off. Version-Release number of selected component (if applicable): upstart-0.6.5-3.fc13.x86_64 How reproducible: always Steps to Reproduce: 1. install F12 2. yum upgrade to F13 Actual results: cannot restart # /sbin/init 1 init: Failed to connect to socket /com/ubuntu/upstart: Connection refused Expected results: restarts fine
I have had this same failure on 3 systems upgraded via the yum upgrade method this weekend. All three required a hard power off to restart the system.
We've sorta known about this. Upstart 0.6 and Upstart 0.3 have different communication methods. The tools for one can't talk to the daemon for the other. We'll have to think of a way to get around that and at least allow the system to be rebooted (loss of job management is probably inevitable though).
4th system upgraded, same problem. As this prevents remote upgrades from working (requires physical box presence, or some out-of-band method to power cycle the box), I'm going to leave this on the F13Blocker list.
When we first switched to upstart, this was a known issue then and required a release note. Is there a reason that would not be suitable now? (reboot -f should still work fine.)
I didn't try (or know about) reboot -f. is there any way to make that happen automatically if the other methods aren't available/functional?
I'm a bit leery of having an automatic fallback to an unclean shutdown. Will poke upstream for comments.
What happens if you run 'telinit u' first, before trying shutdown?
Whoops, 'telinit u' was neutered. You'd need to run 'kill -TERM 1'.
I've done some testing of this. This would be implemented by (in the upstart spec file): ... %triggerpostun -- upstart < 0.6.0 [ -f /proc/1/exe -a -d /proc/1/root ] && kill -TERM 1 ... PRO: - shutdown would work cleanly, from gnome menus or command line CON: - respawn of gettys on logout (terminal, serial, etc.) don't work without changing runlevels first - gdm is not killed on runlevel change
I wasn't able to boot after upgrading to F-13, so I had no choice but to downgrade to upstart-0.3.x. Works OK now.
Discussed at F13Blocker bug review meeting. While yum upgrading between releases is not part of the release criteria (https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria), we recognize many people do upgrades this way. Moving this issue to F13Target (nice to have).
I don't agree, the fix is simple, make higher version depends for new upstart. In fact, everything was OK as soon as I updated initscripts. So it is a dependency issue for me. Please fix it and don't ignore it. By updating initscripts, this issue was solved.
I just found that "kill -9 1" after a yum upgrade did not crash the machine, but apparently did that I could run "init 6" to reboot. Could that be used as a workaround? I guess that the kernel re-forks init when it goes away, and that the new version thus gets started and can react to the new client programs? Do "kill -9 1" have any bad side effects, or could that be used in %post? Perhaps guarded so it only runs if necessary?
(In reply to comment #12) > I don't agree, the fix is simple, make higher version depends for new upstart. I can understand. I'm happy that live upgrades have worked for you in the past. However, live upgrades to new releases of Fedora are not recommended. For details, please see http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum If you have concerns about this policy, please direct them to the 'live upgrade' special interest group (http://fedoraproject.org/wiki/SIGs/LiveUpgrade_Live_Upgrade_Special_Interest_Group). > In fact, everything was OK as soon as I updated initscripts. So it is a > dependency issue for me. Please fix it and don't ignore it. Moving this issue to F13Target doesn't mean it will be ignored. It only means it does not impact the Fedora release criteria [1] and therefore would not cause slip when releasing Fedora 13 if this were the only unresolved issue remaining. [1] https://fedoraproject.org/wiki/Fedora_Release_Criteria
upstart-0.6.5-5.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/upstart-0.6.5-5.fc13
upstart-0.6.5-5.fc13 has been pushed to the Fedora 13 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/upstart-0.6.5-5.fc13
upstart-0.6.5-5.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
For folks coming from http://fedoraproject.org/wiki/YumUpgradeFaq#Fedora_12_-.3E_Fedora_13, I just performed an upgrade of an F-12 installation to F-13 and 'shutdown -r now' worked OK for me. I did that over an SSH connection to the VM running F-12 (some 20,000 km away actually :-).
Simple 'reboot' worked for me just fine.