Using variable in command path for ExecStart in systemd service [closed] - linux

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
Im trying to make a systemd service like below :
[Unit]
Description=Syslog
[Service]
Type=simple
Environment="TESTEXTSERVICESFILES=/opt/test/extservices"
Environment="TESTCONFDATA=/storage/test/conf"
ExecStartPre=/bin/echo ${TESTEXTSERVICESFILES}/syslog/bin/nxlog $TESTCONFDATA
ExecStart=/opt/test/extservices/syslog/bin/nxlog -c ${TESTCONFDATA}/syslog/nxlog.conf
#ExecStart=/${TESTEXTSERVICESFILES}/syslog/bin/nxlog -c ${TESTCONFDATA}/syslog/nxlog.conf
[Install]
WantedBy=multi-user.target
After running 'sudo systemctl daemon-reload ; sudo systemctl start test-syslog ; sudo systemctl status test-syslog', I get the following success output:
● test-syslog.service - TestSyslog
Loaded: loaded (/usr/lib/systemd/system/test-syslog.service; enabled; vendor preset: disabled)
Active: deactivating (stop-sigterm) since Fri 2018-02-23 10:15:09 UTC; 11ms ago
Process: 9474 ExecStart=/./opt/test/extservices/test-syslog/bin/nxlog -c ${TESTCONFDATA}/test-syslog/nxlog.conf (code=exited, status=0/SUCCESS)
Process: 9471 ExecStartPre=/bin/echo /.${TESTEXTSERVICESFILES}/test-syslog/bin/nxlog $TESTCONFDATA (code=exited, status=0/SUCCESS)
Main PID: 9474 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/test-syslog.service
└─9478 /./opt/test/extservices/test-syslog/bin/nxlog -c /storage/test/conf/test-syslog/nxlog.conf
Feb 23 10:15:09 lt-x260-1606.test.local systemd[1]: test-syslog.service: control process exited, code=exited status=0
Feb 23 10:15:09 lt-x260-1606.test.local systemd[1]: test-syslog.service got final SIGCHLD for state start-pre
Feb 23 10:15:09 lt-x260-1606.test.local systemd[1]: About to execute: /./opt/test/extservices/test-syslog/bin/nxlog -c ${TESTCONFDATA}/test-syslog/nxlog.conf
Feb 23 10:15:09 lt-x260-1606.test.local systemd[1]: Forked /./opt/test/extservices/test-syslog/bin/nxlog as 9474
Feb 23 10:15:09 lt-x260-1606.test.local systemd[1]: test-syslog.service changed start-pre -> running
Feb 23 10:15:09 lt-x260-1606.test.local systemd[1]: Job test-syslog.service/start finished, result=done
Feb 23 10:15:09 lt-x260-1606.test.local systemd[1]: Started Test Syslog.
Feb 23 10:15:09 lt-x260-1606.test.local systemd[1]: Child 9474 belongs to test-syslog.service
Feb 23 10:15:09 lt-x260-1606.test.local systemd[1]: test-syslog.service: main process exited, code=exited, status=0/SUCCESS
Feb 23 10:15:09 lt-x260-1606.test.local systemd[1]: test-syslog.service changed running -> stop-sigterm
Here the service has started successfully. But when I comment the first ExecStart directive and uncomment the second one I get
as failure :
● test-syslog.service - Test Syslog
Loaded: loaded (/usr/lib/systemd/system/test-syslog.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Fri 2018-02-23 10:11:44 UTC; 11ms ago
Process: 9243 ExecStart=/$TESTEXTSERVICESFILES/test-syslog/bin/nxlog -c $TESTCONFDATA/test-syslog/nxlog.conf (code=exited, status=203/EXEC)
Process: 9239 ExecStartPre=/bin/echo /.${TESTEXTSERVICESFILES}/test-syslog/bin/nxlog $TESTCONFDATA (code=exited, status=0/SUCCESS)
Main PID: 9243 (code=exited, status=203/EXEC)
Feb 23 10:11:44 lt-x260-1606.test.local echo[9239]: /./opt/test/extservices/test-syslog/bin/nxlog /storage/test/conf
This time the service cannot start, like it doesnt want to start the process starting by ${TESTEXTSERVICESFILES} variable. Does someone have any idea why it is not working even if command lines are the same in both cases ?

You can't use variables in the actual command. systemd.service:
The command to execute must be an absolute path name. It may contain
spaces, but control characters are not allowed.
You might wan't to wrap it in a shell command (which does parameter expansion):
ExecStart=/bin/bash -c '/${TESTEXTSERVICESFILES}/syslog/bin/nxlog -c ${TESTCONFDATA}/syslog/nxlog.conf'

Instead of Environment=, use EnvironmentFile=, to define multiple environment variables.
[Service]
Type=simple
EnvironmentFile=/etc/sysconfig/customsyslog
ExecStart=/bin/echo ${TESTEXTSERVICESFILES}/syslog/bin/nxlog $TESTCONFDATA
/etc/sysconfig/customsyslog would contain key=value pair, e.g.,
TESTEXTSERVICESFILES=/opt/test/extservices
TESTCONFDATA=/storage/test/conf

An old message that I've just stumbled on but looks like your ExecStart line that doesn't work may have 2 '/' at the beginning. One from the ExecStart line before the variable and one from the variable which is declared as /opt/test/extservices
Just a thought.

Related

ssh service is not getting started after upgrading debian 8 jessie to debian 9 strech

ssh service is not getting started after upgrading debian 8 jessie to debian 9 strech
● ssh.service - OpenBSD Secure Shell server Loaded: loaded
(/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2021-05-28 13:36:30 UTC;
10min ago Process: 2155 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
(code=exited, status=255) Process: 2152 ExecStartPre=/usr/sbin/sshd
-t (code=exited, status=0/SUCCESS) Main PID: 2155 (code=exited, status=255)
May 28 13:36:29 ip-172-31-43-40 systemd[1]: Starting OpenBSD Secure
Shell server... May 28 13:36:30 ip-172-31-43-40 systemd[1]:
ssh.service: Main process exited, code=exited, status=255/n/a May 28
13:36:30 ip-172-31-43-40 systemd[1]: Failed to start OpenBSD Secure
Shell server. May 28 13:36:30 ip-172-31-43-40 systemd[1]: ssh.service:
Unit entered failed state. May 28 13:36:30 ip-172-31-43-40 systemd[1]:
ssh.service: Failed with result 'exit-code'.
kindly check the source list, in your source list might be something that disables the SSH
kindly use the different source list
Kindly change your /etc/apt/source.list to this Link it might work.

Bash script doesn't launch with systemd

I'm trying to launch a simple bash script called script-startup.sh when my raspberry Pi boots, using systemd. This script only contains some basic actions on files (copying, moving, executing binaries) and calls make as well to compile bits of codes.
I created a new file with path /etc/systemd/system/baymabx.service :
[Unit]
Description=Baymabx
After=pm2-pi
[Service]
ExecStart=/home/pi/Desktop/baymabx/script-startup.sh
Launching /home/pi/Desktop/baymabx/script-startup.sh in the terminal works as it is intended to be. Also, pm2-pi.service is pm2 starting my backend server, that I need before using my script.
However, after doing systemctl start baymabx and systemctl status baymabx, I get :
● baymabx.service - Baymabx
Loaded: loaded (/etc/systemd/system/baymabx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2020-12-11 01:34:06 CET; 3min 2s ago
Process: 359 ExecStart=/home/pi/Desktop/baymabx/script-startup.sh (code=exited, status=203/EXEC)
Main PID: 359 (code=exited, status=203/EXEC)
Dec 11 01:34:06 raspberrypi systemd[1]: Started Baymabx.
Dec 11 01:34:06 raspberrypi systemd[359]: baymabx.service: Failed to execute command: Exec format error
Dec 11 01:34:06 raspberrypi systemd[359]: baymabx.service: Failed at step EXEC spawning /home/pi/Desktop/baymabx/script-startup.sh: Exec format error
Dec 11 01:34:06 raspberrypi systemd[1]: baymabx.service: Main process exited, code=exited, status=203/EXEC
Dec 11 01:34:06 raspberrypi systemd[1]: baymabx.service: Failed with result 'exit-code'.
Anyone know how I can get it to work ?

Unable to run node app using systemd

This going to be my first node deployment. I have this app which runs fine on my Debian 9 server using this command:
cd /srv/myapp && NODE_ENV=production yarn start
And print out this message:
yarn run v1.6.0
$ babel-node index.js
In order to demonize the app using systemd, I created `/lib/systemd/system/myapp.service:
[Unit]
Description=Myapp
[Service]
ExecStart=/home/john/start.sh
Type=simple
User=john
Restart=on-failure
[Install]
WantedBy=multi-user.target
and in start.sh I have:
cd /srv/myapp && NODE_ENV=production yarn start
Hoewever, when I run systemctl start myapp the node app does not start to listen on port 3000, as expected (netstat -tulpn | grep :3000
returns no results)
# systemctl status myapp
● myapp.service - Myapp
Loaded: loaded (/lib/systemd/system/myapp.service; disabled; vendor preset: enabled
Active: failed (Result: exit-code) since Sun 2018-05-13 06:14:04 EDT; 5s ago
Process: 8852 ExecStart=/home/bob/start.sh (code=exited, status=203/EXEC)
Main PID: 8852 (code=exited, status=203/EXEC)
May 13 06:14:04 9606 systemd[1]: myapp.service: Unit entered failed state.
May 13 06:14:04 9606 systemd[1]: myapp.service: Failed with result 'exit-code'.
May 13 06:14:04 9606 systemd[1]: myapp.service: Service hold-off time over, scheduling
May 13 06:14:04 9606 systemd[1]: Stopped myapp.
May 13 06:14:04 9606 systemd[1]: myapp.service: Start request repeated too quickly.
May 13 06:14:04 9606 systemd[1]: Failed to start myapp.
May 13 06:14:04 9606 systemd[1]: myapp.service: Unit entered failed state.
May 13 06:14:04 9606 systemd[1]: myapp.service: Failed with result 'exit-code'.
I have other variations on myapp.service but could not manage to run node.
What could be wrong here? How can I fix it?
Process: 8852 ExecStart=/home/bob/start.sh (code=exited, status=203/EXEC)
According to systemd.exec(5), this means systemd could not execute the specified file:
203 EXIT_EXEC The actual process execution failed (specifically, the execve(2) system call). Most likely this is caused by a missing or non-accessible executable file.
You should check if /home/bob/start.sh is executable and has correct shebang specified (that is, the first line of your script must be #!/bin/bash).

systemd server isn't started

I am running this systemd command but when I screen -ls I don't see the screen.
The status is active and seems well.
But it isn't actually running when I check.
This is the .service file
[Unit]
Description=webhookdaemon
[Service]
ExecStart=/bin/bash path/to/script
RemainAfterExit=yes
Type=forking
Restart=on-failure
RestartSec=30
[Install]
WantedBy=multi-user.target
Here is the script (path/to/script)
screen -S docker-hub-daemon -d -m npm run start --prefix /root/nodeserver/
Here is the status output
webookdaemon.service - webhookdaemon
Loaded: loaded (/etc/systemd/system/webookdaemon.service; enabled; vendor preset: enabled)
Active: active (exited) since Tue 2018-03-13 19:55:15 UTC; 57min ago
Main PID: 2144 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/webookdaemon.service
Mar 13 19:58:29 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 19:59:03 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:00:22 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:01:21 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:02:26 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:04:41 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:47:41 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:49:53 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
Mar 13 20:52:53 aggregate-terminal-logs-tor1-01 systemd[1]: Started webhookdaemon.
root#aggregate-terminal-logs-tor1-01:~#
You should not be using screen to manage services. Just use systemd directly.
Make sure that Type= is set match the behavior of the service you are lauching. I could not find references to docker-hub-daemon, so I'm not sure the appropriate value for it. See man systemd.service for the documentation for Type=.
Instead of using screen -ls to check the status of the service, use systemctl status webookdaemon.
You may also wish to update the spelling of this service to be webhoookdaemon to match the spelling in the description.

unit falling into a failed state (status=143) when stopping service [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
here is my problem. I have CentOS and java process running on it. Java process is operated by the start/stop script. It creates a .pid file of java instance too.
My unit file is looking like:
[Unit]
After=syslog.target network.target
Description=Someservice
[Service]
User=xxxuser
Type=forking
WorkingDirectory=/srv/apps/someservice
ExecStart=/srv/apps/someservice/server.sh start
ExecStop=/srv/apps/someservice/server.sh stop
PIDFile=/srv/apps/someservice/application.pid
TimeoutStartSec=0
[Install]
WantedBy=multi-user.target
When I call stop function, script terminates java process with SIGTERM and returns 0 code:
kill $OPT_FORCEKILL `cat $PID_FILE`
<...>
return 0
After that, if I check the status of my unit, I get something like that (status=143):
● someservice.service - Someservice
Loaded: loaded (/usr/lib/systemd/system/someservice.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2017-08-30 09:17:40 EEST; 4s ago
Process: 48365 ExecStop=/srv/apps/someservice/server.sh stop (code=exited, status=0/SUCCESS)
Main PID: 46115 (code=exited, status=143)
Aug 29 17:10:02 whatever.domain.com systemd[1]: Starting Someservice...
Aug 29 17:10:02 whatever.domain.com systemd[1]: PID file /srv/apps/someservice/application.pid not readable (yet?) after start.
Aug 29 17:10:04 whatever.domain.com systemd[1]: Started Someservice.
Aug 30 09:17:39 whatever.domain.com systemd[1]: Stopping Someservice...
Aug 30 09:17:39 whatever.domain.com server.sh[48365]: Stopping someservice - PID [46115]
Aug 30 09:17:40 whatever.domain.com systemd[1]: someservice.service: main process exited, code=exited, status=143/n/a
Aug 30 09:17:40 whatever.domain.com systemd[1]: Stopped Someservice.
Aug 30 09:17:40 whatever.domain.com systemd[1]: Unit someservice.service entered failed state.
Aug 30 09:17:40 whatever.domain.com systemd[1]: someservice.service failed.
When I haven't got the return value in my start/stop script, it acts absolutely the same.
Adding into the unit file something like:
[Service]
SuccessExitStatus=143
is not good idea for me. Why the systemctl acting so and doesn't show me normal service state?
When I try to modify my start/stop script and instead of return 0 I put return 10 it acts the same, but I can see that exit 10 is passed.
Here is an example:
● someservice.service - Someservice
Loaded: loaded (/usr/lib/systemd/system/someservice.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2017-08-30 09:36:22 EEST; 5s ago
Process: 48460 ExecStop=/srv/apps/someservice/server.sh stop (code=exited, status=10)
Process: 48424 ExecStart=/srv/apps/someservice/server.sh start (code=exited, status=0/SUCCESS)
Main PID: 48430 (code=exited, status=143)
Aug 30 09:36:11 whatever.domain.com systemd[1]: Starting Someservice...
Aug 30 09:36:11 whatever.domain.com systemd[1]: PID file /srv/apps/someservice/application.pid not readable (yet?) after start.
Aug 30 09:36:13 whatever.domain.com systemd[1]: Started Someservice.
Aug 30 09:36:17 whatever.domain.com systemd[1]: Stopping Someservice...
Aug 30 09:36:17 whatever.domain.com server.sh[48460]: Stopping someservice - PID [48430]
Aug 30 09:36:21 whatever.domain.com systemd[1]: someservice.service: main process exited, code=exited, status=143/n/a
Aug 30 09:36:22 whatever.domain.com systemd[1]: someservice.service: control process exited, code=exited status=10
Aug 30 09:36:22 whatever.domain.com systemd[1]: Stopped Someservice.
Aug 30 09:36:22 whatever.domain.com systemd[1]: Unit someservice.service entered failed state.
Aug 30 09:36:22 whatever.domain.com systemd[1]: someservice.service failed.
From the journalctl log I can see that systemctl firstly returns the status=143 and then my return value of 10. So i guess that my mistake is somewhere in start/stop script (because error code 143 is passed before function returns 0)?
You should be able to suppress this by adding the exit code into the unit file as a "success" exit status:
[Service]
SuccessExitStatus=143
source

Resources