0

If I do this in a script, the call to status shows "OK"

  1. systemctl enable foo
  2. systemctl start foo
  3. systemctl status foo

But only a few milliseconds later the status is "failed".

How can I detect if the start was successful?

What means "successful" for me here: The server started to run.

Systemd seams to start the process and does not wait to see if the server was able to start correctly.

Example: The config of the server contains a syntax error. The server will run for some milliseconds but then terminate.

The most simple solution would be to execute "sleep 1" before my call to "systemctl status foo".

But this feels dirty.

Maybe there is a better solution to get the real status after starting the server.

I only care about the starting. If the server fails two hours later, this is not part of this question.

guettli
  • 3,113
  • 14
  • 59
  • 110
  • what service you are trying to start exactly and what are the logs of that service is saying? – ostendali Oct 23 '15 at 10:34
  • @ostendali for me the concrete service is not important in this question. But if you are curious, it is a custom service for running autossh: http://serverfault.com/questions/730239/start-n-processes-with-one-systemd-service-file – guettli Oct 23 '15 at 12:29
  • The problem isn't on systemd or in any other systemd artifact that starts your service. The problem is the script that starts your service, the init script that systemd is executing have a problem, and it's NOT systemd's fault that your script doesn't do its job properly. Fix your script and systemd will happily work as you expect. – Marcel Nov 05 '15 at 08:38
  • @Marcel My script calls systemd, but systemd does not start an init-script. It starts the server itself. I don't understand what you mean with "fix your script". What do you meant with "fix your script"? – guettli Nov 05 '15 at 09:33

1 Answers1

1

Usually, you get failed state in that command output for started process, when:

  1. Process exits with status which is not equal to 0 or with status, different from SuccessExitStatus parameter specified in unit file's [Service] section
  2. Unclean signal sent to the daemon (kill etc)
  3. Timeout when starting daemon, can be set via TimeoutStartSec or TimeoutSec, default is value of DefaultTimeoutStartSec, which usually is 90 seconds or as set in system.conf, [Manager] section
  4. Watchdog (when type=notify), same as above, controlled by WatchdogSec, RuntimeWatchdogSec

The service must call sd_notify(3) regularly with "WATCHDOG=1" (i.e. the "keep-alive ping"). If the time between two such calls is larger than the configured time, then the service is placed in a failed state

  1. typeis incorrectly set in unit file

  2. GuessMainPID

Takes a boolean value that specifies whether systemd should try to guess the main PID of a service if it cannot be determined reliably. This option is ignored unless Type=forking is set and PIDFile= is unset because for the other types or with an explicitly configured PID file, the main PID is always known. The guessing algorithm might come to incorrect conclusions if a daemon consists of more than one process. If the main PID cannot be determined, failure detection and automatic restarting of a service will not work reliably. Defaults to yes.

GioMac
  • 4,444
  • 3
  • 24
  • 41