Systemd unit startup

Support Software & Applications
1

I have a systemd unit

[Unit]
Description=Start scripts
After=network-online.target 
Requires=network-online.target

[Service]
Type=simple
RemainAfterExit=yes
ExecStartPre=/usr/bin/git stash
ExecStartPre=/usr/bin/git pull
ExecStart=/usr/bin/python connection.py
WorkingDirectory=/home/pi/raspberry-dashboard
User=pi

[Install]
WantedBy=multi-user.target

But the journalctl -b -u dashboard.service shows

[pi@pi ~]$ journalctl -b -u dashboard.service 
-- Journal begins at Fri 2021-10-29 16:07:00 UTC, ends at Tue 2022-04-12 10:59:40 UTC. --
Apr 12 10:58:49 pi systemd[1]: Starting Start scripts...
Apr 12 10:58:50 pi git[434]: No local changes to save
Apr 12 10:58:50 pi git[479]: fatal: unable to access 'https://github.com/caedenph/raspberry-dashboard/': Could not resolve host>
Apr 12 10:58:50 pi systemd[1]: dashboard.service: Control process exited, code=exited, status=1/FAILURE
Apr 12 10:58:50 pi systemd[1]: dashboard.service: Failed with result 'exit-code'.
Apr 12 10:58:50 pi systemd[1]: Failed to start Start scripts.

Indicating that the git pull failed due to what I would assume to be lack of network connectivity. I googled this error and there are also some ideas about proxy’s not ready. However, I have

After=network-online.target
Requires=network-online.target

Which supposedly waits until the network is ready. What am I missing?

2

You ar missing that Manjaro does not support Raspberry Pi OS.

The issue is off-topic for Manjaro.

3

Sorry, my pi is running manjaro minimal

4

Take a look at the systemd manual

Or search the forum - there is quite a few topics on systemd units - also in the archived forum.

5

Output to cat /etc/*-release to confirm

DISTRIB_ID=Manjaro-ARM
DISTRIB_RELEASE=21.10
DISTRIB_CODENAME=
DISTRIB_DESCRIPTION="Manjaro ARM Linux"
NAME="Manjaro-ARM"
ID="manjaro-arm"
ID_LIKE="manjaro arch"
PRETTY_NAME="Manjaro ARM"
ANSI_COLOR="1;32"
HOME_URL="https://www.manjaro.org/"
SUPPORT_URL="https://forum.manjaro.org/c/arm/"
LOGO=manjarolinux
6

name resolution fails

7

I have been taking a look at the manuals, but I’m not entirely sure what I am looking for. Is there a target I need to add to the after or requires, or?

Im not sure what to do with this information, I tried googling it but I am a bit lost. Could I have a little more help please?

8

I know that NetworkManager supplies a NetworkManager-wait-online.service service you can use as a “required/after” target, but our minimal edition does not come with NetworkManager.

“Network Online” does not really mean that a connection has been made, just that the interface has been brought up.

9

Okay;
Do you have any suggestions so that I can use wait for the network to be ready on minimal?

10

Not a systemd specalist here but doesn’t it require URL

https://github.com/CaedenPH/Raspberry-Dashboard.git

and how about?

After=network-online.target nss-lookup.target

Don’t take it for as a suggestion, I know less than you probably.

11

Name resolution is when the system translates the hostname github.com into an IP address.

Roughly it is like when you have a contact named phil and behind that name is phone number.

You say hey google call phil and then the number is looked up and dialed.

Your system has no knowledge - at the time the service is executed - where to ask for the ip address of github.

12

I didnt specify a url in the ExecStartPre; just git pull

I appreciate the help, but unfortunately no banana.

13

git pull implies a connection to the repo - this is stored in the repo/.git/config file - and in this case it is to github

14

I’m aware, but how am I supposed to wait for the next work connection to be active?

15

List the units available on your setup

systemctl list-unit-files | grep network

Two unit files exist - enable either depending on your setup

systemd-networkd-wait-online.service
NetworkManager-wait-online.service

Then add the nss-lookup.target as @raguse suggested

Wants=network-online.target
After=network-online.target
After=nss-lookup.target

Cut the crap! How do I make sure that my service starts after the network is really online?

Well, that depends on your setup and the services you plan to run after it (see above). If you need to delay you service after the network is up, include

After=network-online.target
Wants=network-online.target

in the .service file.

This will ensure that all configured network devices are up and have an IP address assigned before the service is started. network-online.target will time out after 90s. Enabling this might considerably delay your boot even if the timeout is not reached.

The right “wait” service must be enabled too (NetworkManager-wait-online.service if NetworkManager is used to configure the network, systemd-networkd-wait-online.service if systemd-networkd is used, etc.). systemd-networkd.service has Also=systemd-networkd-wait-online.service in its [Install] section, so when systemd-networkd.service is enabled, systemd-networkd-wait-online.service will be enabled too, which means that network-online.target will include systemd-networkd-wait-online.service when and only when systemd-networkd.service is enabled. NetworkManager-wait-online.service is set up similarly. Verify that the right service is enabled (usually only one should be):

$ systemctl is-enabled NetworkManager-wait-online.service systemd-networkd-wait-online.service
disabled
enabled
1 Like
16

Sorry for the delay,

This shows a bunch of units with systemd-networkd-wait-online.service enabled disabled being one of the displayed units. This indicates that the systemd-networkd-wait-online service is enabled. I ran the systemctl is-enabled on the systemd-networkd-wait-online to confirm (I cant run it on the NetworkManager because that doesnt exist)
Unfortunately, the After=nss-lookup.target doesnt work I dont think. My current service unit looks like

[Unit]
Description=Start scripts
Wants=network-online.target
After=network-online.target 
After=nss-lookup.target
Requires=network-online.target

[Service]
Type=simple
RemainAfterExit=yes
ExecStartPre=/usr/bin/git stash
ExecStartPre=/usr/bin/git pull
ExecStart=/usr/bin/python connection.py
WorkingDirectory=/home/pi/raspberry-dashboard
User=pi

[Install]
WantedBy=multi-user.target

Is this correct?

17

Have you reloaded the system daemon after changing the units?

systemctl daemon-reload

I don’t think you need Requires because that is inferred from Wants and After and the nss-lookup.target should ensure nameservice is available too which you need to run the git pull.

To quote from above link

network-online.target

Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a service that delays further execution until the network is sufficiently set up. What precisely this requires is left to the implementation of the network managing service.

Note the distinction between this unit and network.target. This unit is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality) and pulls in a service which possibly adds substantial delays to further execution. In contrast, network.target is a passive unit (i.e. pulled in by the provider of the functionality, rather than the consumer) that usually does not delay execution much. Usually, network.target is part of the boot of most systems, while network-online.target is not, except when at least one unit requires it. Also see Running Services After the Network is up for more information.

All mount units for remote network file systems automatically pull in this unit, and order themselves after it. Note that networking daemons that simply provide functionality to other hosts (as opposed to consume functionality of other hosts) generally do not need to pull this in.

systemd automatically adds dependencies of type Wants= and After= for this target unit to all SysV init script service units with an LSB header referring to the “$network” facility.

Note that this unit is only useful during the original system start-up logic. After the system has completed booting up, it will not track the online state of the system anymore. Due to this it cannot be used as a network connection monitor concept, it is purely a one-time system start-up concept.

18

Everytime I change the unit I always reload the system daemon and reboot the pi.
Unfortunately, even without the Requires= param in the unit it still doesnt work. Any ideas why?

19

Another possibility is the network has not become available at all and as a consequence the service times out at 90s.

Wireless networking perhaps?

20

I am connected via ethernet and when I run sudo systemctl restart dashboard.service it works just fine