Mir-kiosk: Restart apps after refresh

snap
1

I’m running chromium-mir-kiosk on mir-kiosk and it’s working as expected. However, when the mir-kiosk snap gets refreshed, chromium-mir-kiosk will not be restarted as well. This leaves my display with a black screen from mir-kiosk until I restart chromium-mir-kiosk manually. Since the device I’m building is meant to be hands-off, always-on it has no keyboard attached and its users cannot be expected to connect via SSH and run shell commands.

  1. Can this be configured somewhere?
  2. Is this an issue only with chromium-mir-kiosk (i.e. do other kiosk apps using mir-kiosk restart fine)? 2.1 If so, what could be the culprit? Xwayland?

Pinging @alan_g and @greyback – thank you again in advance :slight_smile:

2

Hi @tobias,

Can you please have a look into journalctl -u 'snap.chromium-mir-kiosk.*' when mir-kiosk gets restarted (snap restart mir-kiosk is a good way) and see whether Chromium gets restarted (and how often)? Does the service end up disabled by systemd (systemctl status snap.chromium-mir-kiosk.*) due to failures?

I’m running some tests on my own.

Just a reminder that chromium-mir-kiosk is a proof of concept, no warranties.

3

Hi it’s likely due to the fact that when mir-kiosk stops for the refresh, chromium-mir-kiosk stops unexpectedly. systemd then tries to relaunch chromium-mir-kiosk immediately, but mir-kiosk isn’t ready yet, so c-m-k fails again & again, and so systemd stops retrying it.

That’s the problem anyway. I believe all GUI apps have this problem. Proper solution is for some kind of runtime dependency chain between mir-kiosk and any connected apps. It may be possible with socket activation, but probably easiest thing it for the c-m-k startup script to wait until the wayland socket has been created.

Fancy giving it a go? Note that chromium-mir-kiosk is a proof of concept and not something we support for commercial deployments. I’ll accept for bugfixes tho :slight_smile:

1 Like
4

Actually I just checked and chromium-mir-kiosk never tries to restart, since its restart condition is set to on-failure and on Mir exit, it is a simple shutdown so systemd never tries to restart chromium-mir-kiosk.

@tobias have a look at the snapcraft docs for improvements, you can systemctl edit snap.chromium-mir-kiosk.chromium-mir-kiosk.service to add an appropriate Restart= stanza.

Come to Launchpad, too, if you’d like to propose a change to the snap itself.

1 Like
5

Belated thanks for your insta-help @Saviq and @greyback! Sorry for the long delay, been fiddling with gadget snaps.

Per @Saviq 's advice, I added a restart condition to the service definition in my snapcraft.yaml:

# snapcraft.yaml
apps:
  chromium-mir-kiosk:
    command: desktop-launch xwayland-kiosk-launch chromium-browser.launcher
    daemon: simple
    restart-condition: always # <<--
    desktop: usr/share/applications/chromium.desktop

I chose always to ensure that c-m-k restarts on all possible failures, since my use-case is a completely unattended and keyboard-less device. If that’s acceptable for the upstream snap, I’d be happy to propose the change on Launchpad directly :slight_smile:

6

Hi @tobias
I’d welcome the change. Code lives here at the moment:


I need to re-spin the snap after that (taking in updated Chromium and security patches)
Thanks again
-G

7

Hey @greyback, I tried to propose a merge of my fork’s branch mir-kiosk into yours, but I guess I’m doing something wrong. Not very familiar with Launchpad collaboration yet. I’m using the LP “propose for merging” button on my fork’s branch page, but it err’s out with “lp:~glancr/+git/chromium-snap is not mergeable into this repository.”

image
image1540×1348 241 KB

8

Hi @tobias,
I merged your change into my branch, thank you.

I’ve some updates to do before it will build, am working on it.
Cheers
-G

1 Like