I am trying to run custom shell script and daemon file at the startup on Ubuntu-20.04-LTS with the below method.
$ sudo nano /etc/systemd/system/custom-startup.service
[Unit]
Description=Custom Startup
[Service]
ExecStart=/home/test/Folder-1/tools/project/custom.sh
ExecStart=/home/test/Folder-1/tools/project/daemon-linux
[Install]
WantedBy=multi-user.target
$ sudo systemctl daemon-reload
$ sudo systemctl enable custom-startup.service
$ sudo systemctl start custom-startup.service
Failed to start custom-startup.service: Unit custom-startup.service has a bad unit file setting.
See system logs and 'systemctl status custom-startup.service' for details.
$ sudo systemctl status custom-startup.service
● custom-startup.service - Custom Startup
Loaded: bad-setting (Reason: Unit custom-startup.service has a bad unit file setting.)
Active: inactive (dead)
Jan 13 13:17:59 Marketing systemd[1]: custom-startup.service: Service has more than one ExecStart= setting, which is only allo>
Jan 13 13:30:55 Marketing systemd[1]: custom-startup.service: Service has more than one ExecStart= setting, which is only allo>
Jan 13 13:32:28 Marketing systemd[1]: custom-startup.service: Service has more than one ExecStart= setting, which is only allo>
Jan 13 13:36:29 Marketing systemd[1]: custom-startup.service: Service has more than one ExecStart= setting, which is only allo>
I can't run more than one ExecStart? Even with single ExecStart it is not working. Any pointers to correct the configuration would be helpful.
Related
Simple systemd service not working as expected
Service name: test.service
[Unit]
Description=Test
ConditionEnvironment=STACK=prod
[Service]
Restart=always
ExecStart=/bin/bash -l -c 'echo "do prod stuff!!!"'
[Install]
WantedBy=default.target
sudo systemctl daemon-reload
sudo service test restart
journalctl -u test -f
Systemd is giving an error when I try to use the ConditionEnvironment setting.
Apr 27 13:16:33 ip-172-31-105-2 systemd[1]: Failed to start Test.
Apr 27 13:19:53 ip-172-31-105-2 systemd[1]: /etc/systemd/system/test.service:3: Unknown lvalue 'ConditionEnvironment' in section 'Unit'
Systemd ConditionEnvironment docs
While writing this question I found the answer.
The ConditionEnvironment setting was added in systemd version 246.
See release notes here
Seems Ubuntu is shipping with earlier versions.
ubuntu ~$ systemctl --version
systemd 237 (245.4-4ubuntu3.6)
Notes on updating systemd here: https://askubuntu.com/questions/627174/how-would-i-upgrade-systemd
I try to install vnc-server on my centos 7 server by following the steps below:
1) We install vnc-server
sudo yum install tigervnc-server
After, you’ve installed the program, login with the user you want to run the VNC program and issue the below command in terminal in order to configure a password for the VNC server.
su - your_user # If you want to configure VNC server to run under this user directly from CLI without switching users from GUI
$ vncpasswd
add a VNC service configuration file for your user via a daemon configuration file placed in systemd directory tree. In order to copy the VNC template file you need to run the following command with root privileges.
cp /lib/systemd/system/vncserver#.service /etc/systemd/system/vncserver#:1.service
On the next step edit the copied VNC template configuration file from /etc/systemd/system/ directory and replace the values to reflect your user as shown in the below
vi /etc/systemd/system/vncserver#\:1.service
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target
[Service]
Type=forking
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l my_user -c "/usr/bin/vncserver %i -geometry 1280x720"
PIDFile=/home/my_user/.vnc/%H%i.pid
ExecStop=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
[Install]
WantedBy=multi-user.target
After you’ve made the proper changes to VNC service file, reload systemd system initialization program to pick up the new vnc configuration file and start the TigerVNC server.
systemctl daemon-reload
# systemctl start vncserver#:1
# systemctl status vncserver#:1
# systemctl enable vncserver#:1
Obtaining the following error
systemctl daemon-reload
[root#ns363691 ~]# systemctl start vncserver#:1
Job for vncserver#:1.service failed because a configured resource limit was exceeded. See "systemctl status vncserver#:1.service" and "journalctl -xe" for details.
[root#ns363691 ~]# systemctl status vncserver#:1
● vncserver#:1.service - Remote desktop service (VNC)
Loaded: loaded (/etc/systemd/system/vncserver#:1.service; disabled; vendor preset: disabled)
Active: failed (Result: resources) since mié 2019-11-13 02:09:07 CET; 14s ago
Process: 7605 ExecStart=/usr/sbin/runuser -l root -c /usr/bin/vncserver %i -geometry 1280x720 (code=exited, status=0/SUCCESS)
Process: 7593 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
nov 13 02:09:04 ns363691 systemd[1]: Starting Remote desktop service (VNC)...
nov 13 02:09:07 ns363691 systemd[1]: Can't open PID file /home/root/.vnc/ns363691:1.pid (yet?) after start: No such file or directory
nov 13 02:09:07 ns363691 systemd[1]: Failed to start Remote desktop service (VNC).
nov 13 02:09:07 ns363691 systemd[1]: Unit vncserver#:1.service entered failed state.
nov 13 02:09:07 ns363691 systemd[1]: vncserver#:1.service failed.
Any idea why the service does not start, what is this doing wrong? :(
I am trying to start a service named pigpiod.service via systemd. It invokes a script with three commands. The second one is left out. Why is this?
/etc/systemd/system/pigpiod.service:
[Unit]
Description=Starts pigpiod
Before=touchscreen.service
[Service]
ExecStart=/home/sysop/pigpiod.sh
[Install]
WantedBy=multi-user.target
/home/sysop/pigpiod.sh:
#!/bin/sh
touch /home/sysop/before_pigpiod
/usr/bin/pigpiod
touch /home/sysop/after_pigpiod
When restarting the machine the two files get created in /home/sysop/, but pigpiod is not starting.
When starting the service manually via sudo systemctl start pigpiod the same happens.
When running sudo /home/sysop/pigpiod.sh manually pigpiod is actually starting!
This is the output of sudo systemctl status pigpiod -l right after boot:
● pigpiod.service - Starts pigpiod
Loaded: loaded (/etc/systemd/system/pigpiod.service; enabled)
Active: inactive (dead) since Sat 2017-09-16 20:02:03 UTC; 2min 29s ago
Process: 440 ExecStart=/home/sysop/pigpiod.sh (code=exited, status=0/SUCCESS)
Main PID: 440 (code=exited, status=0/SUCCESS)
Sep 16 20:02:02 kivypie systemd[1]: Starting Starts pigpiod...
Sep 16 20:02:02 kivypie systemd[1]: Started Starts pigpiod.
Why is it, that systemd skips the execution of /usr/bin/pigpiod, but manually running the script as root does not?
My system: Raspberry Pi Model 3B, Raspbian GNU/Linux 8 (jessie)
pigpiod forks without the -g option. So use Type = forking or use pigpiod -g
[Unit]
Description=Starts pigpiod
Before=touchscreen.service
[Service]
ExecStart=/home/sysop/pigpiod.sh
Type=forking
[Install]
WantedBy=multi-user.target
I'm trying to manage multiple redis instances with systemd. Below is my systemd unit file
[Unit]
Description=Redis instances
After=network.target
[Service]
Type=simple
ExecStart=/home/redis/bin/redis-server /home/redis/conf/redis-%i.conf
ExecStop=/home/redis/bin/redis-cli -p %i INFO # <= INFO should not stop redis process
User=redis
Group=redis
[Install]
WantedBy=multi-user.target
I could successfully start redis-server by
$ sudo systemctl start redis#6379
$ systemctl status redis#6379
● redis#6379.service - Redis instances
Loaded: loaded (/usr/lib/systemd/system/redis#.service; disabled; vendor preset: disabled)
Active: active (running) since Tue 2017-09-05 17:48:42 JST; 2h 52min ago
Main PID: 86962 (redis-server)
CGroup: /system.slice/system-redis.slice/redis#6379.service
└─86962 /home/redis/bin/redis-server 0.0.0.0:6379 [cluster]
As a test of stopping redis-server, I intentionally used INFO instead of SHUTDOWN at the ExecStop line.
But when I executed below command, systemd still killed my redis process.
sudo systemctl stop redis#6379
And there's no output by:
sudo journalctl -f -u redis#6379
I wonder how could this happen ?
PS:
I replaced redis-cli with an non-exist one:
ExecStop=/tmp/nonexist
journalctl showed error log like:
Sep 05 20:51:57 myhost systemd[96306]: Failed at step EXEC spawning /tmp/nonexist: No such file or directory
Sep 05 20:51:57 myhost systemd[1]: redis#6379.service: control process exited, code=exited status=203
Sep 05 20:51:57 myhost systemd[1]: Unit redis#6379.service entered failed state.
Sep 05 20:51:57 myhost systemd[1]: redis#6379.service failed.
But the running redis process was still killed.
I want to run a script at system startup in a Debian 9 box. My script works when run standalone, but fails under systemd.
My script just copies a backup file from a remote server to the local machine:
#!/bin/sh
set -e
/usr/bin/sshpass -p "PASSWORD" /usr/bin/scp -p USER#10.0.0.2:ORIGINPATH/backupserver.zip DESTINATIONPATH/backupserver/
Just for privacy I replaced password, user, and paths above.
I wrote the following systemd service unit:
[Unit]
Description=backup script
[Service]
Type=oneshot
ExecStart=PATH/backup.sh
[Install]
WantedBy=default.target
Then I set permissions for the script:
chmod 744 PATH/backup.sh
And installed the service:
chmod 664 /etc/systemd/system/backup.service
systemctl daemon-reload
systemctl enable backup.service
When I reboot the script fails:
● backup.service - backup script
Loaded: loaded (/etc/systemd/system/backup.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2017-05-13 13:39:54 -03; 47min ago
Main PID: 591 (code=exited, status=1/FAILURE)
Result of journalctl -xe:
mai 16 23:34:27 rodrigo-acer systemd[1]: backup.service: Main process exited, code=exited, status=6/NOTCONFIGURED
mai 16 23:34:27 rodrigo-acer systemd[1]: Failed to start backup script.
mai 16 23:34:27 rodrigo-acer systemd[1]: backup.service: Unit entered failed state.
mai 16 23:34:27 rodrigo-acer systemd[1]: backup.service: Failed with result 'exit-code'.
What could be wrong?
Solved guys. There was 2 problems:
1 - I had to change the service unit file to make the service run only after network was up. The unit section was changed to:
[Unit]
Description = World server backup
Wants = network-online.target
After = network.target network-online.target
2 - The root user did not have the remote host added to the known host list, unlike the ordinary user I used to test the script.
Failed with result 'exit-code' you could try this on your last line:
# REQUIRED FOR SYSTEMD: 0 means clean no error
exit 0
You may also need to add:
Type=forking
to the systemd entry similar to: https://serverfault.com/questions/751030/systemd-ignores-return-code-while-starting-service
If your service or script does not fork add a & at the end to run it in the background, and exit with 0 fast. Otherwise it will be like a startup that times out and takes forever / seems like frozen service.