system-update panel not blocking screen lock/blank while downloading

Bug #1259326 reported by dobey
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Ubuntu system image
Triaged
Low
Unassigned
ubuntu-system-settings (Ubuntu)
Invalid
Low
Unassigned

Bug Description

The system-update panel is not blocking the screen form locking/blanking, while a download of a new image is in progress. Sometimes this seems to result in the new image not being fully downloaded (or the UI not properly representing the download, and assuming it hasn't been successful), leaving one with an "Install & Restart" button that immediately fails when pressed, with no way to retry the download.

Tags: client
Revision history for this message
Sebastien Bacher (seb128) wrote :

having the screen turned off is fine, the service which is downloading/installing should take a suspend lock though

affects: ubuntu-system-settings (Ubuntu) → ubuntu-system-image
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in system-image (Ubuntu):
status: New → Confirmed
Changed in system-image (Ubuntu):
assignee: nobody → Barry Warsaw (barry)
importance: Undecided → Medium
Revision history for this message
Barry Warsaw (barry) wrote :

Sorry, I don't understand what the problem is. I just tried an update on my device and it seemed to work fine. Also, wouldn't this be a u/i issue but not a problem with system-image-dbus (which is what the ui is communicating with)?

Revision history for this message
Barry Warsaw (barry) wrote :

Oh, I think I understand. You want system-image-dbus to prevent suspends while it's downloading via the powerd dbus api?

Is there any better documentation of this api than this page: https://wiki.ubuntu.com/powerd and http://www.mattfischer.com/blog/?p=460 or UTSL?

Is it better for s-i-dbus to prevent suspends than the system-settings ui?
If so, these would be the steps s-i-dbus takes:

* Do nothing during CheckForUpdate(). If system suspends during this method, it should be easy enough to just recheck.
* Call requestSysState(1) first thing during DownloadUpdate()
* Call clearSysState() when the update finished for any reason (i.e. UpdateDownloaded success signal, UpdateFailed failiure signal,
    or UpdatePaused signal)
* Call requestSysState(1) when a paused update is resumed.

This means that when the ui calls ApplyUpdate() we will *not* requestSysState(1) since the reboot will happen almost immediately. Although, if the state is automatically reset upon reboot, we could probably do it without much harm.

This also means that during a paused download, the system could still suspend.

I think that's it; can you think of anything else?

Changed in ubuntu-system-image:
status: New → Confirmed
importance: Undecided → Medium
milestone: none → 2.1
tags: added: client
Revision history for this message
Barry Warsaw (barry) wrote :

I'm also not sure this will directly address the original description, since AFAICT, the powerd API only gives me the option of preventing suspends. We have no control over display locking and blanking.

I'm also not clear on how blanking or locking would have any effect on system-image-dbus downloading files, unless this causes system-settings to call PauseDownload and never resume it?

Another thought: should system-settings be calling the powerd API instead of system-image-dbus?

Revision history for this message
Sebastien Bacher (seb128) wrote :

it's not likely that settings called PauseDownload, maybe it's another instance of the service not resuming downloads correctly after issues? (e.g the connection might have dropped or something)

Revision history for this message
Barry Warsaw (barry) wrote :

I would /var/log/system-image/client.log and more information on reproducibility to be able to investigate it further.

Revision history for this message
dobey (dobey) wrote :

Sorry. I just now saw all these replies. I was simply trying to describe what I was observing happening. I don't know how the system works exactly in respect to the updater or downloader, and whether it affects the downloads. I also have no idea what "suspend" means in the context of the device, since tablets and phones are meant to be always on, low power devices. If there's actually a difference in screen off and power suspend in that respect, I don't see a way to observe what that difference is, on a live device.

All I want, is for us to avoid situations where download failures can result in being presented as successful, or which can be caused, as a result of the interaction between various services on the system. What I observed was apparent failed or incomplete downloads, being treated as successful, and the UI behaving oddly as a result, such as clicking on 'Install & Reboot' resulting in an error about the update not being downloaded.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Having the log Barry requested would be useful there, the UI works fine with the mock so my default guess would be that it's an issue with the download service/incomplete download not retried/resumed

Changed in ubuntu-system-settings (Ubuntu):
status: New → Incomplete
importance: Undecided → Low
Revision history for this message
Iain Lane (laney) wrote :

I'd prefer s-i-dbus to do this, indeed.

I'll try and reproduce the borked state on suspend and get the log --- that seems to be a separate but related problem to me.

Barry Warsaw (barry)
Changed in ubuntu-system-image:
milestone: 2.1 → none
Revision history for this message
Barry Warsaw (barry) wrote :

I'd like to add this to s-i 2.2, but please let me know whether the steps outlined in comment #4 seem correct.

Changed in ubuntu-system-image:
status: Confirmed → Triaged
Changed in system-image (Ubuntu):
status: Confirmed → Triaged
Barry Warsaw (barry)
Changed in system-image (Ubuntu):
assignee: Barry Warsaw (barry) → nobody
importance: Medium → Low
Changed in ubuntu-system-image:
importance: Medium → Low
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Specification updated. <https://wiki.ubuntu.com/SoftwareUpdates?action=diff&rev2=178&rev1=177> Any manual download or installation should inhibit suspend, whether it is a system update or an app update. Any automatic download should not.

Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

I added bug #1353125 to track the express inhibition since the original bug here was to properly resume and finish, which I think we are reliably doing now.

Revision history for this message
Sebastien Bacher (seb128) wrote :

closing the setting side as invalid, the service should do that

Changed in ubuntu-system-settings (Ubuntu):
status: Incomplete → Invalid
Barry Warsaw (barry)
no longer affects: system-image (Ubuntu)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.