How to schedule systemd user unit after boot?

I am running Fedora IoT (currently 33.20210315.0) on a raspberry pi4.

I have created a systemd user unit that I want to run after boot and before poweroff.

I am storing the unit file at $HOME/.config/systemd/user/.

The unit file is the following:

[Unit]
Description=Transmission pod service

[Service]
Type=oneshot
RemainAfterExit=true
StandardOutput=journal
ExecStart=sh -c "podman pod start transmission"
ExecStop=podman pod stop transmission

[Install]
WantedBy=default.target

The intent is that the pod will start on boot and stop on poweroff. What actually happens is that the pod starts after the rpi4 boots AND I log in, either through SSH or cockpit. And if I log out (instead of time out) after a while the pod stops.

Any idea how to make the service start after boot irrespective if I try to log in afterward or not? (And similarly to make it stop before a poweroff is executed rather than a log out?)

1 Like

I think you may want to put the config file in /etc/systemd/ for that to work.

I went ahead and tested that. Putting the unit file at /etc/systemd/user/ seemed to make no difference.

Putting the unit file at /etc/systemd/system/ and editing it to be something like:

[Unit]
Description=Transmission pod service from podman custodian

[Service]
Type=oneshot
RemainAfterExit=true
StandardOutput=journal
User=localuser
Group=localuser
ExecStart=sh -c "podman pod start transmission"
ExecStop=podman pod stop transmission

[Install]
WantedBy=default.target

resulted in strange behavior.

$ systemctl start transmission-pod

worked. But after rebooting the pi4 the service was not starting. I m doing something wrong, but I can’t find what.

I 'd also prefer avoiding using admin priviliges, but it looks like that may not be an option.

Additionally

$ journalctl -u transmission-pod.service --since=today

returns noting after a reboot - but not after I start the service manually after I ssh in.

I don’t know if it is any different in Cloud or IoT editions, but isn’t this intended behavior of user units in regular Fedora? They start when the user logs in for the first time and continue as long as there is some session for that user. Look like you want a system unit rather than a user unit, in that case you need to put it under /etc/systemd/system/

Because you started the service but didn’t enable it. In order to survive rebooting, the service needs to be enabled. To enable and start the service with one command:

systemctl enable --now transmission-pod
1 Like

Unfortunately the problem is not that the service is not enabled. From my shell:

$ systemctl status transmission-pod4
● transmission-pod4.service - Transmission pod service from podman custodian
     Loaded: loaded (/etc/systemd/system/transmission-pod4.service; enabled; vendor preset: disabled)
     Active: active (exited) since Sun 2021-03-21 22:21:25 EET; 10s ago
    Process: 1679 ExecStart=/usr/bin/podman pod start transmission (code=exited, status=0/SUCCESS)
   Main PID: 1679 (code=exited, status=0/SUCCESS)
        CPU: 435ms

Mar 21 22:21:24 $hostname systemd[1]: Starting Transmission pod service from podman custodian...
Mar 21 22:21:25 $hostname systemd[1]: Finished Transmission pod service from podman custodian.
$ sudo reboot
Connection to $hostname closed by remote host.
Connection to $hostname closed.
$ ssh $hostname 
Boot Status is GREEN - Health Check SUCCESS
Web console: https://$hostname:9090/

$ systemctl status transmission-pod4
● transmission-pod4.service - Transmission pod service from podman custodian
     Loaded: loaded (/etc/systemd/system/transmission-pod4.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Tue 2021-02-02 02:00:24 EET; 1 months 17 days ago
    Process: 812 ExecStart=/usr/bin/podman pod start transmission (code=exited, status=125)
   Main PID: 812 (code=exited, status=125)
        CPU: 270ms

Feb 02 02:00:23 $hostname systemd[1]: Starting Transmission pod service from podman custodian...
Feb 02 02:00:24 $hostname podman[812]: time="2021-02-02T02:00:24+02:00" level=warning msg="The cgroupv2 manager is set to systemd but there is no systemd user session available"
Feb 02 02:00:24 $hostname podman[812]: time="2021-02-02T02:00:24+02:00" level=warning msg="For using systemd, you may need to login using an user session"
Feb 02 02:00:24 $hostname podman[812]: time="2021-02-02T02:00:24+02:00" level=warning msg="Alternatively, you can enable lingering with: `loginctl enable-linger 1000` (possibly as root)"
Feb 02 02:00:24 $hostname podman[812]: time="2021-02-02T02:00:24+02:00" level=warning msg="Falling back to --cgroup-manager=cgroupfs"
Feb 02 02:00:24 $hostname podman[812]: Error: error creating tmpdir: mkdir /run/user/1000: permission denied
Feb 02 02:00:24 $hostname systemd[1]: transmission-pod4.service: Main process exited, code=exited, status=125/n/a
Feb 02 02:00:24 $hostname systemd[1]: transmission-pod4.service: Failed with result 'exit-code'.
Feb 02 02:00:24 $hostname systemd[1]: Failed to start Transmission pod service from podman custodian.

As you can see on the first status call the service appears enabled. But after boot somehow it not only fails but also shows logs from a day it was not even created ??!

I m trying changes to the unit file trying to see what’s wrong. Below is the file that generated the logs above:

$ cat /etc/systemd/system/transmission-pod4.service 
[Unit]
Description=Transmission pod service from podman custodian
Wants=network.target
After=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true
#Type=forking
#Restart=on-failure
StandardOutput=journal
User=$user
Group=$user
ExecStart=podman pod start transmission
ExecStop=podman pod stop transmission

[Install]
WantedBy=multi-user.target

The logs from Feb2 are very weird. That service didn’t exist back then because I wrote it today. I don’t know if Feb2 was when I wrote Fedora IoT and first booted in the rpi4. Moreover I 've cleaned systemd logs with sudo journalctl --vacuum-time=8d so something so old should be appearing at all, right?

I m not really sure what’s going on, don’t know if I should just wipe the sd card and re-install.

1 Like

After spending some time, I read the logs more carefully and realised that I needed to run loginctl enable-linger 1000 for the service to start properly after a reboot.

I think there’s a bug (?) and those logs are getting assigned an incorrect time, which made me ignore them, but it appears that irrespective of the time shown, systemctl status actually shows the latest logs available.

1 Like

I had some more time to test and I saw that enabling linger (through loginctl enable-linger $USER) for the user starts the service after boot, even if it is setup as a user service, like in my first post. So I think I 'd go for that setup.

Thank you everyone for your help and suggestions!

2 Likes