0

Assume that there's an application app installed in the server, and it provides an application control called appctl. As an administrator, I can start/stop/restart the application via appctl:

appctl start
appctl stop
appctl restart

Then I realized that I should use systemctl to do this, so I wrote a app.service and linked the service file to /etc/systemd/system. After reloading the daemon, I can start/stop/restart the application via systemctl:

systemctl start app.service
systemctl stop app.service
systemctl restart app.service

Now my question comes: After stopping my application using appctl restart, the status in system systemctl status app.service said inactive (dead) since 1 hour ago. This does not reflect to the real status of the application. Is it acceptable?

Personally I feel it normal, because I didn't use systemctl to restart. But I'd like to have more arguments, like quotes from documentation, analysis of the systemctl internal mechanism.

1
  • So look at the systemd manuals? If you restart an application outside of the systemd subsystem, it won't know it's status. Feb 7 '18 at 16:02
2

You're right that this is the expected result. I would not expect appctl to prevent it from happening as such. However, it could be worth thinking about how you can encourage the correct usage.

The system administrator probably needs to be informed that they should not directly use appctl start/restart. It is not just that the service state "does not reflect the real status of the application". You've bypassed systemd, losing any advantages e.g. the daemon will inherit various attributes from whatever shell you ran appctl start from. And systemctl stop app.service will not work :). Also any custom shutdown handling e.g. ExecStop= will not run on system shutdown.

systemd's own daemon programs encourage this by being installed under a subdirectory of /usr/lib instead of /usr/bin or /usr/sbin. systemd-udevd, for example, is not in the user's PATH. /usr/libexec/ (subdirectory or not) is available for the same thing. Technically you can do the same thing even when providing a system V style initscript...

However, there are arguments for convenient access to the daemon programs, e.g. when you have a complex config and want to get error messages in the terminal. An example of this would be apache -t.

If you have verbs other than reload (a systemd service can also define ExecReload) and start/restart/stop, you might want to keep them separate. E.g. use the main daemon binary to implement those four, and put anything else in appctl. E.g. Apache's graceful restart would come under this category.

System administrators "should" already understand that starting appd directly has significant disadvantages, even if it is in their PATH, but that appctl is fine to run from their terminal.

2
  • Note: RHEL/CentOS still have the service command, which can redirect as needed, so with a script frobnicate in /usr/libexec/initscripts/legacy-actions/foo, you can still have service foo frobnicate. (I haven't checked if the other big ones do a similar thing.) Feb 7 '18 at 16:50
  • The very very important thing (IMO) about systemctl stop app.service is of course that a server shutdown/reboot is supposed to do it to terminate the service in an orderly fashion, and will not do it if it thinks the service is already dead. Feb 7 '18 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.