No obvious error when Software Centre can't install due to Synaptic being open

[David Green]

Ubuntu Software Center 3.0.5, Ubuntu 10.10

If Synaptic is running and you attempt to install software from the Software Centre, it just sits there with the in progress icon turning (see attached image). It is only when you click on the icon that it says: 'Waiting for synaptic to exit'. A notification would make this more obvious for the user.

<https://wiki.ubuntu.com/SoftwarePackageOperations#general>: "If apt (/var/lib/apt/lists/lock) or dpkg (/var/lib/dpkg/lock) is locked by something other than aptdaemon (STATUS_WAITING_LOCK) for more than 30 seconds, an alert should appear once, '{calling application} can’t install or remove software until {locking program} exits.', with 'Cancel' and 'Keep Waiting' buttons..."

[Kiwinote (kiwinote)]

Hi David! Thanks for your bug report. We probably don't want to display a notification here, but it indeed doesn't make much sense to display a spinning icon with the label 'in progress' when there isn't any progress. We could do something along the lines of either not spinning the icon, or using a different icon, or appending an alert icon to the end of the row.

[Ryan Kitty (gothickitty93)]

I actually think that a notification would be nice, if it used Ubuntu's default desktop notification system (NotifyOSD I think). I agree that no notification about this should have to appear in the Software Center, but perhaps something from NotifyOSD like "Please exit Synaptic to continue installing <package name>".

[Paddy Landau (paddy-landau)]

Agreed with Ryan. A notification is important. Merely adding an icon to the row is insufficient, especially if you leave the Ubuntu Software Centre running in the background while you continue work on something else.

[Matthew Paul Thomas (mpt)]

Ryan, showing a notification bubble might be frustrating if there's a way that the computer can help you solve the problem. It might also be frustrating if there's nothing you can do about the problem. I think we should instead be more interactive, offering to close Synaptic for you to unblock. And it should be Aptdaemon that does this, so that Software Updater and the Dash also benefit.

Sebastian, Is there a way to tell whether it is Synaptic, or another program (such as apt-get), that has the dpkg lock?

If so, would it make sense for aptdaemon to detect whether it is an application with a .desktop file that has the lock, and offer to close it if it is?

And if not, would it make sense to special-case Synaptic, detecting whether it is open and offering to close it?

(Please assign back to me when these questions are answered. Thanks!)

[Michael Vogt (mvo)]

Hello Matthew,

sorry for the slow reply. It is possible in aptdaemon to figure out the name of the application that holds the lock.
I am not sure if there is a generic way of offering to close the application as it would have to be voluntarily and
I don't think there is a generic way for this. For synaptic aptdaemon could send "SIGUSR1" to bring synaptic to
the foreground (it will call gtk_window_present()). Just sending a SIGINT or SIGKILL is probably too dangerous as
a dpkg operation might be in progress.

[Sebastian Heinlein (glatzor)]

Aptdaemon already shows the name of the binary/application which holds the lock in the status message: "Waiting for XXX to exit...". Possible values in real life are aptitude, apt-get, dpkg and synaptic.

The status of the transaction is set to PK_STATUS_ENUM_WAITING_FOR_LOCK on the PackageKit interface and to aptdaemon.enums.STATUS_WATING_FOR_LOCK on the aptdaemon interface which is used by s-c.

So basically all technical requirements are there.

An important use case is the daily update of the cache to check for upgrades. It "currently" doesn't use aptdaemon but calls apt-get update. So you can get random cache locks.

[Sebastian Heinlein (glatzor)]

The "cleanest" solution would be to use aptdaemon for the daily updates and in synaptic. But especially the later one would require a little bit of work.

Since synaptic runs in the user session and aptdaemon doesn't it isn't the job of aptdameon to notify the user. Sending Synaptic to the front doesn't give the user any clue that he has to close it. Furthermore it is a bad idea to close an application without the confirmation of the user. You never know what kind of unapplied changes there are.

[Sebastian Heinlein (glatzor)]

I close bug for aptdaemon since I don't see how we could improve the situation from the daemon side.

The transaction is in the STATUS_WAITING_LOCK state. INMHO software-center should raise the visibility of this state e.g. by showing a persistent in-window notification if the transaction is in this state for a longer time.

If you need any code from the aptdaemon side please feel free to reopen it again.

[Matthew Paul Thomas (mpt)]

Sebastian, I'm reopening this for aptdaemon because I think it should be handled in one place, rather than USC, the Dash, Software Updater, and Software Sources all having to implement it individually.

So, I've designed an alert that should appear to let you know what's going on, with a choice to keep waiting or to cancel the operation. <https://wiki.ubuntu.com/SoftwarePackageOperations?action=diff&rev2=14&rev1=11> Does that all look practical to you?

[Sebastian Heinlein (glatzor)]

Good idea to use a timeout. Could be implemented on the aptdaemon/gtk3widgets level.

Sometimes a background task could block your transaction (e.g. fetching the latest updates) - those background tasks use an apt-get based cron job. We could detect if it is part of the cron job or if the apt-get command runs in a terminal.

Furthermore we could hardcode nice names for apt-get, aptitude and dpkg.