Comment 5 for bug 842799
Revision history for this message
| Matthew Paul Thomas (mpt) wrote Re: Software installation doesn't block session exit | #5 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
I just discussed this with Michael. I may have messed up the details, but here's what I understand.
There are many different kinds of tasks for which you should be prompted to wait before a logout goes ahead. This already happens when you have an unsaved document in a well-behaved application (like GEdit or LibreOffice). Other examples include burning a CD, syncing an audio player, defragmenting a disk, or sculpting something with a 3D printer.
It shouldn't be Unity's job to detect all of these. It shouldn't be Unity's job even to know about any of them in particular; that wouldn't scale. That's why there's a gnome-session API for individual applications to announce that now would not be a good time to log out ... not yet ... not yet ... okay, now's good. http://
However, for package installation and removal, it's not so simple. As you point out, Sebastian, Ubuntu Software Center may not be running any more while an installation or removal completes. But beyond that, aptdaemon is running on the system bus, not the session bus. This has the advantage that you don't even need to be logged in *at all* for a task to complete. But it has two disadvantages. First, if a Debconf question occurs, there's no-one to answer it. And second, there is, apparently, no system-level equivalent to the gnome-session API for aptdaemon to inhibit shutdown -- so the machine just shuts down and leaves us with this corrupt package state.
So unless a system-level shutdown inhibit API is implemented, there are two ways to prevent the corruption problem here.
(1) In the short term, inhibit logout when there are any tasks. Michael says update-notifier is an appropriate place to do this, so I'm moving this report there.
(2) In the long term, add a check to the shutdown script so that it waits until all tasks are completed. I'm skeptical about how good this would look (and what happens if a maintainer script hangs?), but we can consider that in more detail later.