systemd forking vs simple?

Question

I am writing my first systemd unit file.

For Type, there are a few choices: forking, simple, etc. I have read the Redhat Documentation on this topic (Table 9.9) , but still am not sure when I should use which option.

Any guidelines?

Answer 1

When you start the service manually from the command line (without using the nohupprefix command or the & suffix to run it in the background, or in other words, just run the command you would put on the ExecStart= line of the .service file), what happens?

a) If the service starts and keeps running, and the prompt does not return until you press Control-C or stop the service in some other way: then Type = simple (or Type = exec if your version of systemd has it) is the right choice.

The practical difference between Type = simple and Type = exec is mostly in error detection: Type = simple will proceed with other jobs as soon as systemd has fork()ed a new process for it, and so it may allow dependent things to proceed even if invoking the actual Exec= command fails. On the other hand, Type = exec will check the Exec= command actually gets invoked successfully and reports a failure if not.

So, if your systemd is new enough to support the Type = exec, you might prefer using it over Type = simple for better error checking. But if you need the boot to proceed as quickly as possible, and rapid detection of the start-up failure of your service is not essential, and/or you wish to be compatible with older versions of systemd, you might still use Type = simple.

b) If the prompt returns but the service keeps running in the background (i.e. the service daemonizes itself on its own), then Type = forking is the right choice.

c) If the service does its job and returns to the prompt without leaving anything running (i.e. the service just adjusts some kernel settings, sends a command to something else or does something similar), then Type = oneshot is probably the right choice. In this case, ExecStart of the service might be the command to "set" something, and ExecStop would be the corresponding command to "unset" it. This type usually benefits of RemainAfterExit=true, so systemd will keep track of the "state" of this service according to whether the thing was most recently "set" or "unset".

The other Type values are special cases. For example, if the service utilizes a D-Bus connection, then Type = dbus might be the best choice. It makes systemd aware of the fact, and then systemd will track this service (and anything that depends on it) by the presence of this service on the D-Bus.

To use Type = notify, the process must be able to connect to Unix socket specified in environment variable $NOTIFY_SOCKET and to report its status by writing messages to that socket whenever necessary. Also, the service file should specify the NotifyAccess option to grant access to the notification socket as appropriate.

There is a command-line utility systemd-notify and a C library function sd_notify(3) you may use to send these messages, but if neither of those is suitable to your requirements, you can just implement your own message sender. The messages required are very simple, and look like shell variable assignments: for example, to notify that the service has successfully completed startup and is ready to serve any incoming requests, the service should send the string equivalent to the output of printf "READY=1\n" to the socket. See man 3 sd_notify for more details on the recognized messages.

Note: many service applications designed to be portable to many Unix-style systems may behave as b) by default, but can be made to work like a) by adding an option (usually described as "don't fork", "keep running in foreground", "don't daemonize" or similar). In that case, if the option has no other side effects, then adding the option and using the a)-type behavior would be preferable for systemd.