I’m struggling to have something executed at shutdown and at startup.
I followed the directions at the URLs below.
https://www.golinuxcloud.com/run-script-systemd-before-login-prompt-linux/
https://www.golinuxcloud.com/run-script-with-systemd-before-shutdown-linux/
As a result I can see my services enabled, though then I cannot see any effect of their possible execution.
What can be wrong?
Thanks in advance!
Andrea
You can use:
systemctl status name-of-script
replace name-of-script with the names of the systemd scripts that you created.
Also note, that if you create scripts in /tmp, chances are after a reboot those scripts will have been deleted. So those articles are a bit weird/strange that they are suggesting to create scripts in /tmp.
You gave me the prompt that led me to find out what was not working, for some reason I cannot yet find.
Both the two configuration was supposed to execute the same script, that simply delays the process end with “sleep”.
By inspecting the status of the second service, in my case the one supposed to be launched before login prompt, I found something like in the lines I report below.
set 15 17:44:52 rockylinux systemd[865]: wastetime2.service: Failed to execute command: Permission denied
set 15 17:44:52 rockylinux systemd[865]: wastetime2.service: Failed at step EXEC spawning /tmp/wastetime: Permission denied
The file wastetime is an executable text with the hashbang #!/bin/bash at the top.
It turned out the problem disappears if I specify the ExecStart as below.
ExecStart=/bin/sh /tmp/wastetime
It seems there’s no way to have that script executed relying just on a hashbang (I tried also with #!/bin/sh).
What I have yet to figure out is why the delay before the shutdown is noticeable and instead the delay before login prompt is not noticeable at all, though a related message appears on the screen and no errors are reported.
As for the pages I mentioned, I didn’t follow the procedure there verbatim, and I wouldn’t place a script in /tmp unless it is a dummy script, as in this case (in my previous attempts I anyway put the script elsewhere).
Thanks anyway! At least not I’m not stuck as before… 
Andrea
Hmm, strange. I’ve just done this, because I’m pretty sure I’ve used hashbangs before and never had issues. So I created /usr/local/bin/test.sh and inside I put:
#!/bin/bash
#
# Test script that doesn't do much
echo "Test for systemd!"
as you can see it doesn’t do much, but will be enough for systemd to check/test it. Now, I create /etc/systemd/system/test.service and inside I put:
[Unit]
Description=Test Service
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/test.sh
[Install]
WantedBy=multi-user.target
The After and WantedBy are probably not needed for this, but it would at least assume that it is runlevel 3 and network is active. I then did:
systemctl daemon-reload
systemctl enable test
systemctl start test
now, when I check the status:
[root@rocky8 system]# systemctl status test
● test.service - Test Service
Loaded: loaded (/etc/systemd/system/test.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Thu 2022-09-15 18:18:16 CEST; 2s ago
Process: 43166 ExecStart=/usr/local/bin/test.sh (code=exited, status=0/SUCCESS)
Main PID: 43166 (code=exited, status=0/SUCCESS)
Sep 15 18:18:16 rocky8 systemd[1]: Started Test Service.
Sep 15 18:18:16 rocky8 test.sh[43166]: Test for systemd!
Sep 15 18:18:16 rocky8 systemd[1]: test.service: Succeeded.
you can see in the second to last line, that the echo command in my script worked. That means, that it’s no problem to have a hashbang. Probably, the content of your system.service file is missing something. Sometimes you have to play around with the type, and it can have a value of simple, oneshot, forking. At least these are ones I have used or attempted to use in the past.
Does it matter whether the executable bit is set on the bash script?
Yeah, executable bit would have to be set.
This is excellent! The best solution so far for running a script at startup thanks!