You are not logged in.

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

captaincurrie
Member
From: /dev/random
Registered: 2013-11-01
Posts: 82

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

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)

Offline

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

jernst
Member
From: Silicon Valley
Registered: 2014-03-04
Posts: 285
Website

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

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

Offline

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

captaincurrie
Member
From: /dev/random
Registered: 2013-11-01
Posts: 82

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

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?

Offline

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

anatolik
Developer
Registered: 2012-09-27
Posts: 458

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

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.


Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster

Offline

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

captaincurrie
Member
From: /dev/random
Registered: 2013-11-01
Posts: 82

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

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 smile

Offline

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

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

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

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.

Offline

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

captaincurrie
Member
From: /dev/random
Registered: 2013-11-01
Posts: 82

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

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 smile

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

Offline

Board footer

Powered by FluxBB