Systemd unit not starting up

Support Third-party Applications
1

I have a systemd unit file which is supposed to run on startup however it is crashing somehow.
jesterbot.service:

[Unit]
Description=Run jesterbot
After=network.target
Requires=network-online.target

[Service]
Type=forking
ExecStart=/usr/bin/tmux new-session -d -s jesterbot 'cd /home/pi/jesterbot && git stash && git pull && python main.py'
User=pi

[Install]
WantedBy=multi-user.target

This doesnt work on startup, however if i run sudo systemctl start jesterbot.service it runs fine. I have installed it, reenabled it, and reloaded the daemon multiple times to make sure im not making a silly error yet it still isnt running on startup.


[pi@pi ~]$ systemctl status jesterbot.service
ā—‹ jesterbot.service - Run jesterbot
     Loaded: loaded (/etc/systemd/system/jesterbot.service; enabled; vendor pre>
     Active: inactive (dead) since Wed 2022-03-30 20:24:38 UTC; 20s ago
    Process: 408 ExecStart=/usr/bin/tmux new-session -d -s jesterbot cd /home/p>
        CPU: 18ms

Mar 30 20:24:38 pi systemd[1]: Starting Run jesterbot...
Mar 30 20:24:38 pi systemd[1]: jesterbot.service: Deactivated successfully.
Mar 30 20:24:38 pi systemd[1]: Started Run jesterbot.
lines 1-9/9 (END)

The command works fine, iā€™ve copy and pasted it into terminal and it runs successfully, iā€™ve checked the Require directory and there is jesterbot.service inside that, etc. Does anyone have any ideas?

2

You might want to try
Type=oneshot and RemainAfterExit=true

3

Whereā€™s the error message?

4

What if you changed:

After=network.target

to

After=network-online.target

The above is based on my experience with httpd and the following serverfault thread and bugzilla entry. After the last update, httpd failed on boot, but started fine manually when the system was up. Although, when I did a status on httpd, there were error messages that clearly indicated there was a timing issue. Double check the journal.

5

Unfortunately, this did not work
This is the journal log

[pi@pi ~]$ journalctl -b -u jesterbot.service
-- Journal begins at Fri 2021-10-29 16:07:00 UTC, ends at Thu 2022-03-31 16:07:>
Mar 31 16:07:38 pi systemd[1]: Starting Run jesterbot...
Mar 31 16:07:38 pi systemd[1]: jesterbot.service: Deactivated successfully.
Mar 31 16:07:38 pi systemd[1]: Started Run jesterbot.
6

I tried that;
jesterbot.service

[Unit]
Description=Run jesterbot
After=network-online.target
Requires=network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/tmux new-session -d -s jesterbot 'cd /home/pi/jesterbot && git stash && git pull && python main.py'
User=pi

[Install]
WantedBy=multi-user.target

systemctl status jesterbot.service:

ā— jesterbot.service - Run jesterbot
     Loaded: loaded (/etc/systemd/system/jesterbot.service; enabled; vendor pre>
     Active: active (exited) since Thu 2022-03-31 16:11:00 UTC; 1min 59s ago
    Process: 444 ExecStart=/usr/bin/tmux new-session -d -s jesterbot cd /home/p>
   Main PID: 444 (code=exited, status=0/SUCCESS)
        CPU: 16ms

Mar 31 16:10:59 pi systemd[1]: Starting Run jesterbot...
Mar 31 16:11:00 pi systemd[1]: Finished Run jesterbot.

And the logs

[pi@pi ~]$ journalctl -b -u jesterbot.service
-- Journal begins at Fri 2021-10-29 16:07:00 UTC, ends at Thu 2022-03-31 16:12:>
Mar 31 16:10:59 pi systemd[1]: Starting Run jesterbot...
Mar 31 16:11:00 pi systemd[1]: Finished Run jesterbot.
7

I would like to note that this service (dashboard.service) performs perfectly

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

[Service]
Type=forking
ExecStart=/usr/bin/tmux new-session -d -s 2 'cd /home/pi/raspberry-dashboard && npx kill-port 8080 && git stash && git pull && npm run start'
User=pi

[Install]
WantedBy=multi-user.target
8

It needs to be Type=forking with tmux. However, because of tmux, you donā€™t see any logs. So nobody knows why it fails. The git commands might be a reason, but nobody can know.

You should really consider stop using tmux, it just makes you live harder with absolutely no benefit. Without tmux, you can use the journal to see whats going on, if it fails you can automatically restart or run extra services that notify you. You can run commands and then restart the service, or stop do something and start again. There is really no reason to use tmux for something like this.

1 Like
9

Agreed.

For all we know, the service is fine, yet the remote target is unavailable for a brief moment before the git commands execute.

Here is an example of a script I invoke via a systemd service.

My ExecStart= points to this script:

#!/bin/bash

if nm-online -q --timeout 30;

	then
 
 	if timeout 21s bash -c 'until ping -c1 -q remoteaddress.com > /dev/null 2>&1 ; do echo "Server unreachable! Retrying!" ; sleep 2s ; done'

        then

			# bunch of commands in here
			echo "Rocket launch!"

		else
	
			echo "Server not reachable for over 20 seconds. Service aborted."
	fi

else

	echo "No network connection available. Service aborted."

fi
10

If I dont use tmux is there a wait to see the stdout of a process?

11

It will be in the journal. You can watch it live, filter it, it will be stored depending on your journald config.

The python command should be the only in ExecStart, you can use ExecStartPre for your git stuff. You can use multiple ExecStartPre commands. Use WorkingDirectory= , since the cd command will not work.
The Type= depends on the python application, but it will not be oneshot.

1 Like
12

Would it be like:

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

[Service]
Type=forking
WorkingDirectory=/home/pi/jesterbot
ExecPre=git stash
ExecPre=git pull
ExecStart=/usr/bin/python main.py
User=pi

[Install]
WantedBy=multi-user.target
13

Probably , you can only try.
However I donā€™t think youā€™ll need a type for such a service.

14

It might be Type=simple ,

Use the full path for the git binary. Similar to python in ExecStart=

If you donā€™t see any output, you might need

ExecStart=/usr/bin/python -u main.py
2 Likes
15

That works, thanks!
Im not entirely sure if this is related, but I now get a stage where putty ā€˜refusesā€™ my connection for about a minute, might my units be holding up the boot process and whatnot?

16

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.