It would be useful if libvrit or virt-manager could block shutdown when virtual machines are actually active to avoid killing them badly if the user forgts they are running and tries to shutdown/reboot the machine. Just like you are prevented form shutting down if there are other users logged in on other consoles (override through root password).
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
(In reply to comment #0) > It would be useful if libvrit or virt-manager could block shutdown when virtual > machines are actually active to avoid killing them badly if the user forgts > they are running and tries to shutdown/reboot the machine. > Just like you are prevented form shutting down if there are other users logged > in on other consoles (override through root password). The libvirt-guests init script was added after this original request was made, which currently lets the user control whether all guests should first be saved (and auto-restored on guest boot), or gracefully shutdown. Is this sufficient for your needs, or do we still need another mode where the existence of a guest blocks shutdown?
These days, /sbin/shutdown is a symlink to /bin/systemctl. I'm reassigning this to the systemd package for help in determining how best to make systemctl prevent shutdown without root authorization if the libvirtd service says a guest is running. Feel free to assign it back to libvirt if it needs to be done in libvirtd's init script.
(In reply to comment #8) > (In reply to comment #0) > > It would be useful if libvrit or virt-manager could block shutdown when virtual > > machines are actually active to avoid killing them badly if the user forgts > > they are running and tries to shutdown/reboot the machine. > > Just like you are prevented form shutting down if there are other users logged > > in on other consoles (override through root password). > > The libvirt-guests init script was added after this original request was made, > which currently lets the user control whether all guests should first be saved > (and auto-restored on guest boot), or gracefully shutdown. Is this sufficient > for your needs, or do we still need another mode where the existence of a guest > blocks shutdown? Yes, it is working just great on my F16 machine, and saved my guests more than once lately. Thank you very much for this one, it is a great feature!
(In reply to comment #9) > These days, /sbin/shutdown is a symlink to /bin/systemctl. I'm reassigning > this to the systemd package for help in determining how best to make systemctl > prevent shutdown without root authorization if the libvirtd service says a > guest is running. I must be missing something. /sbin/shutdown (-> /bin/systemctl) does not allow non-root users to do anything: $ shutdown -h Must be root.
But /usr/bin/reboot (In reply to comment #11) > (In reply to comment #9) > > These days, /sbin/shutdown is a symlink to /bin/systemctl. I'm reassigning > > this to the systemd package for help in determining how best to make systemctl > > prevent shutdown without root authorization if the libvirtd service says a > > guest is running. > > I must be missing something. /sbin/shutdown (-> /bin/systemctl) does not allow > non-root users to do anything: > > $ shutdown -h > Must be root. But /usr/bin/reboot allows non-root to reboot the machine, and at the moment, that even happens even if there are other users logged on at the time. 'man reboot' also points to systemd, but rpm -qf says /usr/bin/reboot points to usermode. Do we need to make usermode smarter? I tried: boot ctrl-alt-f2 login as root ctrl-alt-f3 login as non-root $ reboot and the system rebooted, even though it took out a logged-in root session.
(In reply to comment #12) > Do we need to make usermode smarter? The usermode hack is a really broken concept at many levels, it should just be removed from the system. There are open features/bugs for it already. We have pkexec and sudo for these kind ofoperations. (In)transparently providing tools with root privileges just asks for troubles like this.
Ping what's the current status of this?
Hmm, so we now have hooked up "systemctl poweroff" with policykit, and have two different authroizations for it, one if more than one user is logged in, and one if only one user is logged in. We probably could add another one, that is used whenver some service wants to block shutdown. Shutdown blocking kinda reminds me of the hole suspend blockers discussion. Maybe it should be solved the same way?
We now have shutdown inhibitors in systemd git. As soon as this hits F18 libvirt could start making use of this. The scheme is very simple: just invoke the call org.freedesktop.login1.Manager.Inhibit() on the /org/freedesktop/login1 object on the org.freedesktop.login1 service. It takes three string arguments: "what", "who" and "why". what = what to inhibit, can be one or more of "shutdown", "suspend", "idle", separated by ":". For libvirt only "shutdown" should be relevant. who = some user-readable application identifier (e.g: "Virtualization Manager") why = some user-readable reason for the lock (e.g: "A VM is still running") this call returns only a single fd. That fd encapsulates the lock and should be kept around as long as needed. As soon as it is closed the lock goes away. The effect of taking an inhibitor lock like this is that shutdowns will only be available to privileged clients or those which have a PolicyKit privilege for overriding these inhibits.
systemd-44-9.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/systemd-44-9.fc17
Package systemd-44-9.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-44-9.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-8127/systemd-44-9.fc17 then log in and leave karma (feedback).
Package systemd-44-10.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-44-10.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-8127/systemd-44-10.fc17 then log in and leave karma (feedback).
Package systemd-44-12.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-44-12.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-8127/systemd-44-12.fc17 then log in and leave karma (feedback).
systemd-44-12.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.