[Bug] /usr/libexec/sailfish-osupdateservice osupdate-check sets ssu re

Tracked by Jolla

asked 2019-05-25 18:28:31 +0300

olf gravatar image

updated 2020-05-06 18:44:50 +0300

Table of content


SailfishOS' systemd user unit osupdate-check.timer regularly triggers the systemd user unit osupdate-check.service, which executes /usr/libexec/sailfish-osupdateservice osupdate-check.

Bug description

/usr/libexec/sailfish-osupdateservice osupdate-check sets SSU to the latest release or next "stop release" of SailfishOS, instead of solely checking, if a new release is available and then notifying the user.
The severe consequences do not immediately become apparent to the user:
All tools and applications relying on the package management might offer and incorrectly install RPMs for a newer SailfishOS release than the installed one, or they might fail to install RPMs due to incorrectly resolved dependencies.
Hence this affects the tools store-client, pkcon, rpm, libzypp and zypper supplied by Jolla, plus third party tools as Storeman / Warehouse (Openrepos client apps) and Patchmanager.
Letting any of these tools update all packages it manages then results in failing applications, SailfishOS not working properly or even a completely broken SailfishOS installation.


Let /usr/libexec/sailfish-osupdateservice osupdate-check only perform the check and, if positive, emit an notification, but do not let it set SSU to a different release version than the installed one.
Consequently the output of version | grep -o '[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*' | sed -n '1p' shall always be equal to the output of ssu re | rev | cut -f 1 -d ' ' | rev, unless the user explicitly commands otherwise.


Observed for many months (if not years) on Jolla 1 phones and an Xperia X, each time I did not upgrade to the recent SailfishOS "GA (general availability)" release immediately. Finally I found the time to analyse this annoying issue.

To depict the trigger of the offender
[root]# systemctl --user status osupdate-check.service
● osupdate-check.service - Store client os update check
Loaded: loaded (/usr/lib/systemd/user/osupdate-check.service; static; vendor preset: enabled)
Active: inactive (dead) since Sat 2019-05-25 15:47:30 CEST; 1min 39s ago
Process: 7275 ExecStart=/usr/bin/invoker --type=silica-qt5 -n -d 5 /usr/libexec/sailfish-osupdateservice osupdate-check (code=exited, status=0/SUCCESS)
Main PID: 7275 (code=exited, status=0/SUCCESS)


a. A quick fix, when the version displayed by ssu re differs from the output of version

To resolve this issue until sailfish-osupdateservice osupdate-check is started again (10 minutes after a reboot plus every 7 hours 54 minutes), issue

[root]# ssu re "$(version | grep -o '[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*\.[0-9][0-9]*' | sed -n '1p')"

(which sets SSU to the installed version), followed by a reboot.
Then either run post_sfos-upgrade (if sfos-upgrade is installed)
or manually execute the "Final clean up steps" (specifically killing the store-client followed by removing its cached SailfishOS upgrade release version info),
plus a zypper ref (if zypper is installed) and a pkcon refresh.

But if RPMs or Patchmanager Patches were updated or installed while SSU was set to a different SailfishOS release than the installed one, one should reinstall all these RPMs / Patches or (if these are untraceable) perform a factory reset of SailfishOS.

b. An additional, semi-permanent fix preventing sailfish-osupdateservice osupdate-check to be triggered by osupdate-check.timer

Note that performing a SailfishOS upgrade enables this timer unit again.
Thus redo step b. each time after upgrading Sailfish OS, until Jolla has fixed this (apparently not in SailfishOS 3.3.0).

Edit (2019-06-18): If you want to employ step b., do that before performing step a. (or redo a. after b., if you have already carried out step a.), because meanwhile the sailfish-osupdateservice osupdate-check may have been triggered again (until step b. is done)!

Edit (2019-06-04): A simple
rm /usr/lib/systemd/user/user-session.target.wants/osupdate-check.timer (as root)
followed by a reboot is fully sufficient for performing this step b..

Former description of step b.:

[root]# systemctl --user stop osupdate-check.timer
[root]# systemctl --user disable osupdate-check.timer
[root]# cd /usr/lib/systemd/user/
[root]# mv osupdate-check.timer osupdate-check.timer.orig

A slightly cleaner semi-permanent fix is to remove the symbolic link /usr/lib/systemd/user/user-session.target.wants/osupdate-check.timer -> ../osupdate-check.timer (by executing rm /usr/lib/systemd/user/user-session.target.wants/osupdate-check.timer) instead of renaming the timer unit proper (in the last line above), but a deleted link is harder to remember when one wants to revert this change.

edit retag flag offensive close delete


Is this the reason for the woes of this poster, whose (apparently) OS identifies as


teemu ( 2019-06-09 00:22:34 +0300 )edit

@olf, I recently followed the update process with "journalctl --follow", and:

after Sailfish OS Update (from Settings) has finished downloading an OS update (but before installing the update) the update agent will issue various command that apparently do changes to the 'SSU' information of the device. What exactly is it that happens then, and is that related to this bug?

teemu ( 2019-06-09 10:02:34 +0300 )edit

a. That's different. Rather sounds as if @meolic upgraded at the command line and missed the "Final clean up steps" or to run post_sfos-upgrade (when sfos-upgrade was used for upgrading).

b. No. This is solely about sailfish-osupdate osupdate-check apparently doing more than just checking, not about the upgrade process proper.

olf ( 2019-06-09 18:25:07 +0300 )edit

Thank you very much for your efforts and this detailed report! I have filed an internal bug report about this and hopefully we get it fixed soon.

jiit ( 2019-07-01 10:10:34 +0300 )edit

Nice and thorough description here, thanks. Just to make sure 'ssu s' doesn't return rnd mode on? Without that os update, or more specifically the size check, should return the previous version after done.

Pekka Vuorela ( 2019-07-02 12:18:54 +0300 )edit