1

I have a minimal systemd service that seems to work normally when started manually using systemctl start my-application.service And it stops normally using the corresponding stop command. For some reason during the system boot, the service is correctly started but immediately stopped. I don't understand why there is a different behaviour in these two cases.

The service is configured like this:

[Unit] After=network.target [Service] ExecStart=start-application.sh ExecStop=stop-application.sh SendSIGKILL=no KillMode=none [Install] WantedBy=default.target

The start-application.sh is as follows:

#!/bin/bash . /home/me/app-settings cd /home/me/$APPLICATION/ ./$APPLICATION

The $APPLICATION variable is read from /home/me/app-settings. It simply starts a simple application (I even tried with an application that does nothing but waits for a CTRL+c).

I want to underline that, it seems to work fine when I start the service manually but, when on boot, it starts and immediately stops (calling the ExecStop command).

Using systemctl status I have different outputs when started automatically on boot and when launched using systemctrl start.

After boot

○ gp-application.service Loaded: loaded (/etc/systemd/system/gp-application.service; enabled; preset: enabled) Active: inactive (dead) since Mon 2024-02-19 12:03:09 +01; 19s ago Duration: 1.859s Process: 586 ExecStart=start-application.sh (code=exited, status=0/SUCCESS) Process: 746 ExecStop=stop-application.sh (code=exited, status=0/SUCCESS) Main PID: 586 (code=exited, status=0/SUCCESS) CPU: 64ms Feb 19 12:03:08 controller su[757]: (to gp) root on none Feb 19 12:03:08 controller su[757]: pam_unix(su-l:session): session opened for user gp(uid=1000) by (uid=0) Feb 19 12:03:08 controller su[757]: pam_unix(su-l:session): session closed for user gp Feb 19 12:03:08 controller su[760]: (to gp) root on none Feb 19 12:03:08 controller su[760]: pam_unix(su-l:session): session opened for user gp(uid=1000) by (uid=0) Feb 19 12:03:08 controller su[760]: pam_unix(su-l:session): session closed for user gp Feb 19 12:03:08 controller su[763]: (to gp) root on none Feb 19 12:03:08 controller su[763]: pam_unix(su-l:session): session opened for user gp(uid=1000) by (uid=0) Feb 19 12:03:09 controller su[763]: pam_unix(su-l:session): session closed for user gp Feb 19 12:03:09 controller systemd[1]: gp-application.service: Deactivated successfully.

If started using systemctl start gp-application.service

● gp-application.service Loaded: loaded (/etc/systemd/system/gp-application.service; enabled; preset: enabled) Active: active (running) since Mon 2024-02-19 12:04:32 +01; 4s ago Main PID: 826 (start-applicati) Tasks: 2 (limit: 9279) Memory: 3.2M CPU: 26ms CGroup: /system.slice/gp-application.service ├─826 /bin/bash /usr/local/bin/start-application.sh └─840 . speedy Feb 19 12:04:33 controller su[837]: (to gp) root on none Feb 19 12:04:33 controller su[837]: pam_unix(su-l:session): session opened for user gp(uid=1000) by (uid=0) Feb 19 12:04:33 controller su[837]: pam_unix(su-l:session): session closed for user gp Feb 19 12:04:33 controller start-application.sh[840]: SPEEDY 7.0.0 Feb 19 12:04:33 controller start-application.sh[840]: RT-APP-COMMON 2.0.0 Feb 19 12:04:33 controller start-application.sh[840]: 12:04:33.587 utils.cpp :117 - utilsInit() Utils successfully initialized. Feb 19 12:04:33 controller start-application.sh[840]: 12:04:33.587 utils.cpp :244 - checkAndCreateRTLockFile() RT lock file: /tmp/.rt-app-lock successfully created. Feb 19 12:04:33 controller start-application.sh[840]: 12:04:33.587 main.cpp :768 - InitProgram() Reading font table Feb 19 12:04:33 controller start-application.sh[840]: 12:04:33.587 fnttable.cpp :144 - ReadFontTable() Error font file font12x8.aff Feb 19 12:04:33 controller start-application.sh[840]: 12:04:33.587 common-parread.cpp :83 - readCommonParameters() EventSocket disabled as requested via parameter file.
Improve this question
7
  • Does your application fork? Why do you have logger after ./$APPLICATION? Commented Feb 19, 2024 at 10:37
  • You're right, it doesn't make any sense as the application doesn't fork Commented Feb 19, 2024 at 10:42
  • An application waiting for Ctrl-C would require a terminal attached, but systemd doesn't provide one because applications started as services are supposed to run in non-interactive mode. Commented Feb 19, 2024 at 10:50
  • Yes, that's why in the stop-application.sh I send a kill -INT to stop the application. But the problem it's not that it doesn't stop but that the ExecStop command is called immediately after the ExecStart but ONLY when the system is booting Commented Feb 19, 2024 at 10:55
  • Most likely your application stops because you are launching an interactive application in a non-interactive environment. Check your service logs with systemctl status my-application.service for more details. Commented Feb 19, 2024 at 11:01

1 Answer 1

Reset to default
1

As AlexD pointed out, the application was starting but immediately stopped, with exit code 0/SUCCESS.

As specified in the docs, after the application exits with SUCCESS, the ExecStop command is automatically called.

The reason the application stopped is not related to systemd itself, as I could see looking at the application logs, as AlexD suggested.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.