Cloning to libvirt to take advantage of the systemd enhancements. +++ This bug was initially created as a clone of Bug #570594 +++ 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). --- Additional comment from fedora-admin-xmlrpc on 2011-09-22 11:49:54 MDT --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from fedora-admin-xmlrpc on 2011-09-22 11:52:50 MDT --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from fedora-admin-xmlrpc on 2011-09-22 11:58:10 MDT --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from fedora-admin-xmlrpc on 2011-11-30 12:30:36 MST --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from fedora-admin-xmlrpc on 2011-11-30 12:34:18 MST --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from fedora-admin-xmlrpc on 2011-11-30 12:40:40 MST --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from fedora-admin-xmlrpc on 2011-11-30 12:51:50 MST --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from eblake on 2011-11-30 17:48:16 MST --- (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? --- Additional comment from eblake on 2011-11-30 17:56:12 MST --- 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. --- Additional comment from ssorce on 2011-11-30 19:35:50 MST --- (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! --- Additional comment from mschmidt on 2011-12-01 06:19:54 MST --- (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. --- Additional comment from eblake on 2011-12-01 08:12:39 MST --- 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. --- Additional comment from kay on 2011-12-01 09:47:12 MST --- (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. --- Additional comment from johannbg on 2012-02-27 03:33:37 MST --- Ping what's the current status of this? --- Additional comment from lpoetter on 2012-03-12 20:45:31 MDT --- 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? --- Additional comment from lpoetter on 2012-04-16 13:17:07 MDT --- 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. --- Additional comment from updates on 2012-05-18 17:38:38 MDT --- systemd-44-9.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/systemd-44-9.fc17 --- Additional comment from updates on 2012-05-19 12:33:53 MDT --- 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). --- Additional comment from updates on 2012-05-21 10:55:24 MDT --- 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). --- Additional comment from updates on 2012-05-22 09:55:07 MDT --- 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). --- Additional comment from updates on 2012-05-29 04:34:26 MDT --- 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.
This does currently not work in Fedora 17 because of Bug #843836.
RFE -> Moving to the upstream tracker
The systemd docs/API are here: https://www.freedesktop.org/wiki/Software/systemd/inhibit/ I figure this would be a libvirtd.conf option too. Not sure exactly how this is handled in the desktop
Thank you for reporting this issue to the libvirt project. Unfortunately we have been unable to resolve this issue due to insufficient maintainer capacity and it will now be closed. This is not a reflection on the possible validity of the issue, merely the lack of resources to investigate and address it, for which we apologise. If you none the less feel the issue is still important, you may choose to report it again at the new project issue tracker https://gitlab.com/libvirt/libvirt/-/issues The project also welcomes contribution from anyone who believes they can provide a solution.