Description of problem: I'm not sure where sshd comes from here. In an xterm, I do this: zooty> sudo su -l Last login: Fri Jul 25 20:16:09 EDT 2014 on pts/0 [root@zooty ~]# exit logout zooty> reboot User root is logged in on sshd. Please retry operation after closing inhibitors and logging out other users. Alternatively, ignore inhibitors and users with 'systemctl reboot -i'. zooty> Apparently the act of doing "sudo su -l" make systemd believe it should generate the error shown above, even though I exited from that su session. Version-Release number of selected component (if applicable): systemd-208-20.fc20.x86_64 How reproducible: Seems to be every time. Steps to Reproduce: 1.see above 2. 3. Actual results: can't reboot anymore Expected results: can reboot Additional info: Even when I switch to root to reboot so it won't complain, it takes forever for the reboot to actually finish. It is apparently timing out on the imaginary root sshd session.
Waht's "sudo su -l" supposed to be? You become root, and then you become root again inside of it? "We must go deeper!" Does "sudo -s" have the same effect? Do you have anybody else logged in at the same time if you type "w" or "who"?
(In reply to Lennart Poettering from comment #1) > Waht's "sudo su -l" supposed to be? That gets me a shell in which root's .bash_profile has executed, setting up PATH, aliases, etc. as root expects them so commands operate as expected. > Does "sudo -s" have the same effect? Don't know because I can't reproduce this now. I have gotten the newer systemd-208-21.fc20.x86_64 since I submitted the bug, so perhaps it was fixed by something that changed since 208-20. > Do you have anybody else logged in at the same time if you type "w" or "who"? Just my normal user running X. When I was experimenting with this, I rebooted several times, so someone else logging in would have needed really good timing.
OK, closing. If you can reproduce this, please reopen.