As I mentioned in my other thread, I’m working on an app to handle on-call alerts. Obviously it’d be unacceptable for something like the low memory killer to kill the part which polls for new alerts, so what’s the best way to ensure that this doesn’t happen? My current though is to spin off a daemon from the “app” as it’s seen on the home screen, which lets me receive pages even if it’s closed, but how do I keep that around? Am I able to define a user-level systemd service for it which allowed for auto-restarting whenever it’s killed or would something like that be restricted for battery life reasons?
1 Like
Yes you can, standard user-session systemd units are supported, and you can “Restart=on-abnormal” or similar as usual.
Just be careful that you place the unit file in the right place, and be sure to use the correct dependencies (post-user-session, lipstick, home mounted etc).
Wrongly configured systemd services have resulted in non-bootable devices in the past.
You can either have your rpm package install under %{_userunitdir} (/usr/lib/systemd/user), or if you have a GUI or settings app, make that place a unit file into ~/.config/systemd/user/.
You should not however mix the two approaches, i.e. you should not have the RPM install into /home.
2 Likes
A single rectification:
No, please do not do that, because the directory %{_userunitdir} (i.e. on SailfishOS, /usr/lib/systemd/user ) is for user units deployed by system packages (i.e., RPM files).
One shall use the directory %{_sysconfdir}/systemd/user (i.e. on SailfishOS, /etc/systemd/user ) for user units installed by third party software.
I fully concur to all other statements by @nephros especially …
[…] if you have a GUI or settings app, make that place a unit file into
~/.config/systemd/user/.