0

I've provisioned a bunch of RPis with a systemd service that runs an instance of chromium-browser in kiosk mode, but on a few seemingly random devices it doesn't run. I checked the status just by trying to enable it and I get

$ sudo systemctl enable kiosk.service
Failed to enable unit: Unit file /lib/systemd/system/kiosk.service is masked.

I looked up what it means for it to become "masked" in order to understand how this happened, and responses simply state that "the units are linked to /dev/null". Okay, but why did that happen to my service? ~~systemctl unmask kiosk.service will unmask my service but~~ (scratch that, see edit below) I'd like to make sure it doesn't continue to happen.

Here is the actual "kiosk.service" contents if relevant:

[Unit]
Description=Chromium Kiosk
Wants=graphical.target
After=graphical.target

[Service]
ExecStartPre=/bin/sleep 20
Environment=DISPLAY=:0.0
Environment=XAUTHORITY=/home/pi/.Xauthority
Type=simple
ExecStart=/bin/bash /home/pi/kiosk.sh
Restart=on-abort
User=pi
Group=pi

[Install]
WantedBy=graphical.target

EDIT:

Actually sudo systemctl unmask kiosk.service doesn't seem to do anything. When I do that then sudo systemctl enable kiosk.service it returns the same complaint that it's masked.

EDIT2:

So instead of succesfully being able to unmask I simply deleted lib/systemd/system/kiosk.service and re-subscribed it as a service, now it appears to remain enabled. Still have no idea why it was masked to begin with.

Improve this question

2 Answers 2

Reset to default
1

The message

Unit file /lib/systemd/system/kiosk.service is masked.

suggests that a package-provided /lib/systemd/system/kiosk.service is actually a symbolic link to /dev/null. The systemctl mask only ever creates such symlinks under /etc/systemd/.

So, that normally means the symbolic link was included in the package that provided the service, and usually that is because there is a SysVinit-style /etc/init.d/kiosk script meant for use with a non-systemd init systems, but when using systemd, the package might instead use two or more separate services, to allow systemd to monitor them independently. The symbolic link blocks the service autogenerated from the SysVinit startup script from starting, and allows the native service unit(s) to take its place.

If your chromium-kiosk package is actually this one: https://github.com/Salamek/chromium-kiosk then the "main" systemd service provided by the package is actually named chromium-kiosk_configwatcher.service.

Looking at the history of the package, it seems it has been fairly significantly refactored in 2022. The masking symlink might actually be a defensive measure against old legacy-style boot scripts left over from previous versions of the package, as I don't see any SysVinit-style startup script in the sources for the current version.

If you have some RPis that actually use kiosk.service, it might be that you are running different versions of this package: the ones with a "functioning" kiosk.service might have been installed before the refactoring, and the ones with the kiosk.service masked might be installed after the refactor, or may have been updated to the post-refactor version (perhaps automatically, thanks to unattended-upgrades or similar update automation package).

Improve this answer
0

It needs either a reboot, or use unmask --now

sudo systemctl unmask --now kiosk.service
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.