search

freedomofpress / securedrop-workstation

Qubes-based SecureDrop Journalist Workstation environment for submission handling
GNU Affero General Public License v3.0
141 stars 43 forks source link

App does not launch after updater-enforced reboot #663

Open eloquence opened 3 years ago

eloquence commented 3 years ago

In https://github.com/freedomofpress/securedrop-workstation/issues/662#issuecomment-796263387 @conorsch observed an issue with the app not launching automatically after an updater-enforced reboot:

There was one small hiccup I noticed during testing, which I don't believe is related to the release changes, and so shouldn't block promotion to prod. After the updater completed and I rebooted, I wasn't able to start the Client from the desktop icon. Checking the logs, it the lock blocked it from starting. While I could have run gtk-launch securedrop-client myself, I didn't, and instead rebooted again. The Client started without issue. Here are the logs from that session:

2021-03-10 14:32:45,462 - sdw_updater_gui.UpdaterApp:77(upgrade_status) INFO: Signal: upgrade_status {'recommended_action': <UpdateStatus.REBOOT_REQUIRED: '2'>, 'dom0': <UpdateStatus.REBOOT_REQUIRED: '2'>, 'apply_dom0': '0'}
2021-03-10 14:32:45,465 - sdw_updater_gui.UpdaterApp:82(upgrade_status) INFO: Reboot required
2021-03-10 14:34:22,818 - sdw_updater_gui.UpdaterApp:145(reboot_workstation) INFO: Rebooting the workstation
2021-03-10 14:37:06,546 - __main__:46(main) INFO: Starting SecureDrop Launcher
2021-03-10 14:37:06,549 - sdw_updater_gui.Updater:451(should_launch_updater) INFO: Required reboot performed, updating status and launching client.
2021-03-10 14:37:06,549 - sdw_updater_gui.Updater:216(_write_updates_status_flag_to_disk) INFO: Setting update flag to 0 in sd-app
2021-03-10 14:37:42,498 - sdw_util.Util:70(obtain_lock) ERROR: Error obtaining lock on '/run/user/1000/sdw-launcher.lock'. Process may already be running.
2021-03-10 14:38:51,331 - sdw_util.Util:70(obtain_lock) ERROR: Error obtaining lock on '/run/user/1000/sdw-launcher.lock'. Process may already be running.
2021-03-10 14:39:26,729 - sdw_util.Util:70(obtain_lock) ERROR: Error obtaining lock on '/run/user/1000/sdw-launcher.lock'. Process may already be running.
2021-03-10 14:39:28,044 - sdw_util.Util:70(obtain_lock) ERROR: Error obtaining lock on '/run/user/1000/sdw-launcher.lock'. Process may already be running.
2021-03-10 14:44:21,392 - __main__:46(main) INFO: Starting SecureDrop Launcher
2021-03-10 14:44:21,400 - sdw_updater_gui.Updater:451(should_launch_updater) INFO: Required reboot performed, updating status and launching client.
2021-03-10 14:44:21,401 - sdw_updater_gui.Updater:216(_write_updates_status_flag_to_disk) INFO: Setting update flag to 0 in sd-app
2021-03-10 14:44:39,908 - sdw_updater_gui.Updater:225(_write_updates_status_flag_to_disk) INFO: Setting update flag to 0 in dom0
2021-03-10 14:44:39,909 - sdw_updater_gui.UpdaterApp:27(launch_securedrop_client) INFO: Launching SecureDrop client
eloquence commented 3 years ago

I've not observed this issue myself yet. It's important to note that the updater is intended to just silently launch the app after a reboot, and a logged lock file error when attempting to start it manually while it is doing its thing is expected. However, as Conor noted, the app did not launch for several minutes. Could be an issue with reboot flags, flag/lock interaction, or something else entirely, and will likely require some timeboxed testing to get a clean repro.

eloquence commented 3 years ago

No repro yet; just had a dom0 update with reboot, and tried clicking the desktop icon while it was auto-launching. I see the "Error obtaining lock" line in the log as expected (because auto-launch was underway), but the app window came up with no issue.