[Solved] systemd - To fork or not to fork when writing services

captaincurrie · 2014-12-31 09:04:41

Hello,

Many of the programs i write services for have the option to fork or not to fork. Or are
advertised as daemons but have the ability to not fork into the background.

I don't understand which i should choose when writing a new service unit.

When do you want a program to run in 'daemon-mode' and when don't you?

Do i lose/gain anything when i make such a choice?

Thank you.

Last edited by captaincurrie (2015-01-01 12:32:11)

jernst · 2015-01-01 00:49:55

My understanding is that in case of

Type=simple

systemd will fork your daemon. In case of

Type=forking

your daemon needs to fork itself, and then quit before systemd continues.

See http://www.freedesktop.org/software/sys … rvice.html

captaincurrie · 2015-01-01 08:20:43

jernst wrote:

My understanding is that in case of
Type=simple
systemd will fork your daemon. In case of
Type=forking
your daemon needs to fork itself, and then quit before systemd continues.
See http://www.freedesktop.org/software/sys … rvice.html

Thats not what i'm asking. I want to know why, or why not, would you want your service to fork when it has the
option not to fork. Many programs come with options to fork in the background or not to fork.
Take mpd for example. It is the Music Player Daemon yet you can run it with the
option no-daemon. I don't know which mode i want it running in when i encapsulate it
in a systemd service.

What considerations would make you choose one or the other?

anatolik · 2015-01-01 12:13:05

captaincurrie wrote:

I want to know why, or why not, would you want your service to fork when it has the
option not to fork. Many programs come with options to fork in the background or not to fork.
Take mpd for example. It is the Music Player Daemon yet you can run it with the
option no-daemon. I don't know which mode i want it running in when i encapsulate it
in a systemd service.

If you have a choice then use Type=simple for your systemd services. It is simpler and systemd will take care or proper process deamonizing, restarts and shutdowns.

Type=forking is for historical services that cannot be run in foreground. In this case process itself will take care of its deamonizing, but systemd should know the child pid somehow so you need to provide PIDFile= option as well.

captaincurrie · 2015-01-01 12:31:50

anatolik wrote:

captaincurrie wrote:
I want to know why, or why not, would you want your service to fork when it has the
option not to fork. Many programs come with options to fork in the background or not to fork.
Take mpd for example. It is the Music Player Daemon yet you can run it with the
option no-daemon. I don't know which mode i want it running in when i encapsulate it
in a systemd service.
If you have a choice then use Type=simple for your systemd services. It is simpler and systemd will take care or proper process deamonizing, restarts and shutdowns.
Type=forking is for historical services that cannot be run in foreground. In this case process itself will take care of its deamonizing, but systemd should know the child pid somehow so you need to provide PIDFile= option as well.

Ok. Sounds good to me. Perhaps when i understand things a little deeper i'll know the more subtle nuances of 'when and when not'
I'll use this rule until then.

Thank you

falconindy · 2015-01-01 20:17:09

anatolik wrote:

[If you have a choice then use Type=simple for your systemd services. It is simpler and systemd will take care or proper process deamonizing, restarts and shutdowns.
Type=forking is for historical services that cannot be run in foreground. In this case process itself will take care of its deamonizing, but systemd should know the child pid somehow so you need to provide PIDFile= option as well.

Historical or not, Type=forking is necessary if you need to be able to order other services on the Type=forking service. Type determines the readiness protocol used by systemd. In the case of Type=simple, there is no protocol. systemd assumes that as soon as the binary is exec'd, the service is available. For Type=forking, services are considered ready after the MainPID exits (after the double fork), allowing for time to setup sockets or other resources needed to handle client requests (e.g. a database server or a web server). If you use the Type, you may find that dependent services fail to startup properly, as their dependencies aren't actually ready when systemd declares them to be.

captaincurrie · 2015-01-11 12:59:26

falconindy wrote:

anatolik wrote:
[If you have a choice then use Type=simple for your systemd services. It is simpler and systemd will take care or proper process deamonizing, restarts and shutdowns.
Type=forking is for historical services that cannot be run in foreground. In this case process itself will take care of its deamonizing, but systemd should know the child pid somehow so you need to provide PIDFile= option as well.
Historical or not, Type=forking is necessary if you need to be able to order other services on the Type=forking service. Type determines the readiness protocol used by systemd. In the case of Type=simple, there is no protocol. systemd assumes that as soon as the binary is exec'd, the service is available. For Type=forking, services are considered ready after the MainPID exits (after the double fork), allowing for time to setup sockets or other resources needed to handle client requests (e.g. a database server or a web server). If you use the Type, you may find that dependent services fail to startup properly, as their dependencies aren't actually ready when systemd declares them to be.

Thank you, that really cleared it up for me

After your response, and re-reading the manual, it all makes sense now!

Arch Linux

#1 2014-12-31 09:04:41

[Solved] systemd - To fork or not to fork when writing services

#2 2015-01-01 00:49:55

Re: [Solved] systemd - To fork or not to fork when writing services

#3 2015-01-01 08:20:43

Re: [Solved] systemd - To fork or not to fork when writing services

#4 2015-01-01 12:13:05

Re: [Solved] systemd - To fork or not to fork when writing services

#5 2015-01-01 12:31:50

Re: [Solved] systemd - To fork or not to fork when writing services

#6 2015-01-01 20:17:09

Re: [Solved] systemd - To fork or not to fork when writing services

#7 2015-01-11 12:59:26

Re: [Solved] systemd - To fork or not to fork when writing services

Board footer