On 24/05/13 11:29, Dmitrijs Ledkovs wrote:
> As far as I understand (correct me if I am wrong), systemd instead of
> counting/tracking forks uses cgroups to keep track of the started
> processes.
systemd uses cgroups to track "which processes are part of this
service?", which means the services may be configured to do traditional
Unix daemonization (double-fork), or remain "in the foreground",
whichever is easier.
One advantage of leaving the services forking is that some daemons
effectively use the fork() as a signal that they are ready for use
(because the point at which they fork and go to the background is the
point at which their sysvinit-style init script would exit). For a
"simple" daemon that doesn't fork, init can't necessarily tell when it's
actually ready, which can be a problem when doing aggressive
parallelization.
systemd has several ways to tell that a service is ready, configured
with the "[Service] Type" key in the .service file: the service could
fork when it's ready (Type=forking), it could take a D-Bus name when
it's ready (Type=dbus), or it could use the systemd-specific
sd_notify(3) to tell systemd explicitly (Type=notify). For services that
don't do any of those (Type=simple), it can only assume that the service
is instantly ready: that's OK when using socket activation, but usually
not otherwise.
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/519f4f03.8060...@debian.org
