14

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)?

sergei
  • 402
  • 1
  • 5
  • 14
  • The java application itself returns 143. Maybe make it non-forking and wrap in a script that returns 0 instead? – Velkan Aug 30 '17 at 06:50
  • But I kill this application with SIGTERM (or KILL) signal.. and bash returns me 0 exit code, why systemctl interpreting it like 143. – sergei Aug 30 '17 at 07:10
  • The script that kills returns 0 (well, the script that starts returns 0 too). But the application is a completely different process. – Velkan Aug 30 '17 at 07:14
  • 4
    143 looks like a [synthetic exit status](http://blogs.perl.org/users/mauke/2011/09/exit-statuses-and-how-works.html) computed by the shell as 128 + signal number. In your case the signal number would be 143 - 128 = 15, corresponding to SIGTERM. – melpomene Aug 30 '17 at 07:42
  • 1
    Note: a similar problem has been posted here: https://serverfault.com/questions/695849/services-remain-in-failed-state-after-stopped-with-systemctl/695863#695863 – Vassilis Papanikolaou Jan 24 '18 at 15:26
  • Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See [What topics can I ask about here](http://stackoverflow.com/help/on-topic) in the Help Center. Perhaps [Super User](http://superuser.com/) or [Unix & Linux Stack Exchange](http://unix.stackexchange.com/) would be a better place to ask. – jww Mar 24 '18 at 07:49

1 Answers1

16

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

Mohannd
  • 1,288
  • 21
  • 20
  • 3
    can down voters explain way?, the answer to the question depend on Linux Admin Information. Do you think that every java developer should be a Linux Admin? – Mohannd Apr 05 '21 at 18:35