I have a systemd service running on my Pi 2. The first thing this script does is send me a text message to let me know the service was restarted. The text message includes the current timestamp, using Python’s datetime function: response_text = 'System is online: %s' % dt.datetime.now().replace(microsecond=0)
The problem is that on some reboots, the date will be incorrect at startup (off by several days). I assume this is because my job is triggered before OSMC has updated system time from NTP. Does this seem plausible?
If so, is there a systemd command to tell the script to wait for this? I also have it set to wait for network.
Thanks, Sam. I don’t remember doing anything of this nature from the command line. Can you please expand a little on what would be required?
If I had selected (“wait for Network”) from the configurations available in OSMC, is that the service that would have been enabled?
Searching online, it seems that enabling network-online.target requires this command: sudo systemctl enable NetworkManager-wait-online.service
But from the dependency tree shown below, and knowing that OSMC uses connman, is it actually this: sudo systemctl enable connman-wait-for-network.service
I checked to see if either service was already running, and it seems “no” and “maybe”:
osmc@piradio:~$ sudo systemctl status NetworkManager-wait-online.service -l
* NetworkManager-wait-online.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
osmc@piradio:~$ sudo systemctl status connman-wait-for-network.service -l
* connman-wait-for-network.service - Wait for Network to be Configured
Loaded: loaded (/lib/systemd/system/connman-wait-for-network.service; enabled)
Active: inactive (dead) since Sun 2017-05-07 15:24:24 EDT; 6h ago
Process: 292 ExecStart=/bin/bash -c if grep -q nfsroot /proc/cmdline; then exit 0; fi; count=60; while [ $count -gt 0 ]; do if connmanctl state | grep -iq 'ready\|online'; then break; fi; sleep 1; let count-=1; done; exit 0 (code=exited, status=0/SUCCESS)
Main PID: 292 (code=exited, status=0/SUCCESS)
May 07 15:24:16 piradio systemd[1]: Starting Wait for Network to be Configured...
May 07 15:24:24 piradio systemd[1]: Started Wait for Network to be Configured.
I also checked the dependency tree. The dependency connman-wait-for-network.service has a red asterisk, compared to the others green, so I take this to mean it is not running?
I don’t think it’s worth waiting around for network targets or anything like ntp.service. Far better, IMO, is to wait until you reach runlevel 3, where the basic system is up and running, sans the graphical stuff. By this time ntp should have synchronised with its timeservers.
For this you’d need After=multi-user.target
If you want to wait until runlevel 5 use:
After=graphical.target
Here are all the active targets on my Pi 3:
osmc@osmc:~$ systemctl list-units --type target
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
bluetooth.target loaded active active Bluetooth
cryptsetup.target loaded active active Encrypted Volumes
getty.target loaded active active Login Prompts
graphical.target loaded active active Graphical Interface
local-fs-pre.target loaded active active Local File Systems (Pre)
local-fs.target loaded active active Local File Systems
multi-user.target loaded active active Multi-User System
network-online.target loaded active active Network is Online
network.target loaded active active Network
paths.target loaded active active Paths
remote-fs-pre.target loaded active active Remote File Systems (Pre)
remote-fs.target loaded active active Remote File Systems
rpcbind.target loaded active active RPC Port Mapper
slices.target loaded active active Slices
sockets.target loaded active active Sockets
sound.target loaded active active Sound Card
swap.target loaded active active Swap
sysinit.target loaded active active System Initialization
timers.target loaded active active Timers
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
20 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
And if I take this approach, I do not need to enable any target or other additional steps?
This alternate approach would work fine for me, as I can wait a few seconds for my service to start. But I am still curious how to get the network approach working. Would I have had to:
Yes. You haven’t told us where you’ve put the file or how the rest of it looks but that one line should ensure that it runs after runlevel 3 has been reached.
Just to be 100% sure, I made a very simple test service that writes a line to the system log when it runs:
osmc@osmc:~$ cat /etc/systemd/system/rl3.service
[Unit]
Description=Notify syslog when RL 3 is reached
After=multi-user.target
[Service]
Type=simple
ExecStart=/home/osmc/rl3.sh
[Install]
WantedBy=multi-user.target
The last two lines mean that it can be enabled/disabled.
osmc@osmc:~$ systemctl status rl3.service
● rl3.service - Notify syslog when RL 3 is reached
Loaded: loaded (/etc/systemd/system/rl3.service; enabled)
Active: inactive (dead) since Mon 2017-05-08 14:00:54 CEST; 2min 33s ago
Process: 518 ExecStart=/home/osmc/rl3.sh (code=exited, status=0/SUCCESS)
Process: 510 ExecStartPre=/bin/sleep 2 (code=exited, status=0/SUCCESS)
Main PID: 518 (code=exited, status=0/SUCCESS)
It did reveal one interesting fact: that on my Pi 3 I have both eth0 and wlan0 enabled and RL3 was reached after eth0 was up but before wlan0 was up. If that is a problem you can always add an extra line ExecStartPre=/bin/sleep 2 to your .service file.