"systemdctl --user enable name.timer" does not survive reboot

Question

1

"systemdctl --user enable name.timer" does not survive reboot

asked 2020-04-21 13:26:02 +0200

Kobold
276 ●5 ●11 ●11

Hi,

I am setting up additional timers in nemo's user space, which I enable with the command " systemdctl --user enable <name>.timer " Starting the timers everything works as expected and I see the expected outcome of "systemctl --user list-timers.</name>

All well until I reboot my phone. After a reboot, the timers do not start anymore, the timers are not shown in "list-timers" anymore and I need to restart them manually. Confirmed on two Sony Xperia (XA2 and 10) both running 3.3.0.14.

Does anybody have experienced the same issue and knows how to overcome ?

Thanks!

edit retag flag offensive close delete

Comments

show your timer contents

coderus ( 2020-04-21 13:32:19 +0200 )edit

The setup works once I move my timer into /lib/systemd/system, but I fully expect those files to be overwritten with any SFOS update, hence the need to redo my current setup. Expected behaviour is systemd to be able to start user timers as with any other linux system as well, but it clearly is not.

Nevertheless, running my units from /lib/systemd proves my setup being generally correct,

Any help appreciated.

Kobold ( 2020-04-21 18:23:18 +0200 )edit

sure, just shouw contents of your timer file

coderus ( 2020-04-22 01:42:29 +0200 )edit

I'm sorry, I did not see your comment when posting my update, possibly a browser cache thing. My timer file looks like this (Edits to fix incorrect linewraps and star is an in-place substitute for the * as the board breaks the layout if you include one.):

[Unit]

Description=Disable DND mode

[Timer]

OnCalendar=star-star-star 07:00:00

OnBootSec=10s

[Install]

WantedBy = multi-user.target

Kobold ( 2020-04-22 12:30:39 +0200 )edit

1

Take a look at how MeeCast achieves that:

# /usr/lib/systemd/user/dateuptimermeecast.timer

[Unit]
Description=Date uptimer timer

[Timer]
OnBootSec=30
OnCalendar=*-*-* *:00/1:00
Unit=dateuptimermeecast.service

[Install]
WantedBy=user-session.target

This has been working fine since SailfishOS 1.0.x.

P.S.: On first sight, you missed to define a Systemd Unit (e.g., a Service Unit) to be started by your Timer Unit.

olf ( 2020-04-23 21:52:49 +0200 )edit

show your timer contents
coderus ( 2020-04-21 13:32:19 +0200 )edit
The setup works once I move my timer into /lib/systemd/system, but I fully expect those files to be overwritten with any SFOS update, hence the need to redo my current setup. Expected behaviour is systemd to be able to start user timers as with any other linux system as well, but it clearly is not.
Nevertheless, running my units from /lib/systemd proves my setup being generally correct,
Any help appreciated.
Kobold ( 2020-04-21 18:23:18 +0200 )edit
sure, just shouw contents of your timer file
coderus ( 2020-04-22 01:42:29 +0200 )edit
I'm sorry, I did not see your comment when posting my update, possibly a browser cache thing. My timer file looks like this (Edits to fix incorrect linewraps and star is an in-place substitute for the * as the board breaks the layout if you include one.):
[Unit]
Description=Disable DND mode
[Timer]
OnCalendar=star-star-star 07:00:00
OnBootSec=10s
[Install]
WantedBy = multi-user.target
Kobold ( 2020-04-22 12:30:39 +0200 )edit
Take a look at how MeeCast achieves that:
# /usr/lib/systemd/user/dateuptimermeecast.timer [Unit] Description=Date uptimer timer [Timer] OnBootSec=30 OnCalendar=*-*-* *:00/1:00 Unit=dateuptimermeecast.service [Install] WantedBy=user-session.target
This has been working fine since SailfishOS 1.0.x.
P.S.: On first sight, you missed to define a Systemd Unit (e.g., a Service Unit) to be started by your Timer Unit.
olf ( 2020-04-23 21:52:49 +0200 )edit

Answer 1

1

answered 2020-04-23 18:38:53 +0200

DrYak

9624 ●93 ●134 ●128

http://www.sympato.ch/

The problem usually stem from the /home partition not being up at the time systemd scans for service and timers. (Note how the user timer osupdate-check.server is hosted on the root partition, in /usr/lib/systemd/user/).

Nowadays it doesn't happen on a lot of Linux distributions because most systems tend to use a single partition for everything, but since the move to LVM, Sailfish X does have split partitions.

In one of the Raspberry Pi project I have (I use split partition because only F2FS is available at boot time, and I wanted to use BTRFS for /home), I simply have added code in /etc/rc.local to force re-enabling the missing stuff.

You could also try rescanning the --user units (something along the lines of systemctl --user daemon-reload, to be called from within a root service with User=nemo option and which waits for /home to mount, e.g.: After=local-fs.target.) There were caveat in calling reload from within a unit, but saddly I don't remember, and I am not administrating that machine anymore. (Give it a try and google any error message you find in journalctl if it fails).

Note: On Redhat and CentOS specifically, it fails for an entirely different reason: --user units are disabled there, root units are the only solution. Luckily that's not the case on Sailfish OS.

edit flag offensive delete publish link

Comments

Thank you DrYak, that could indeed be the issue I am looking at, let me check and report back.

Kobold ( 2020-04-26 10:43:20 +0200 )edit

"systemdctl --user enable name.timer" does not survive reboot

Comments

1 Answer

Comments

Question tools

Stats

"systemdctl --user enable name.timer" does not survive reboot

Comments

1 Answer

Comments

Question tools

Public thread

Stats