[systemd-devel] when is a service ready to be used after startup?
grawity at gmail.com
Wed Dec 10 04:31:53 PST 2014
On Wed, Dec 10, 2014 at 11:32 AM, Olaf Hering <olaf at aepfle.de> wrote:
> I wonder how systemd handles the startup time of a daemon once it did
> the execve (or whatever systemd does internally). Every daemon needs
> some time until it can service requests.
* With regular services, systemd expects the daemon itself to announce that
it's ready. You use "Type=forking", "Type=notify", "Type=dbus" to choose
which event systemd will wait for.
* With socket-activated services, this doesn't matter at all, since the
requests won't fail, just get queued by the kernel.
> In the following example a socket is provided, a daemon handles the
> socket and another tool will use the socket. How can I make sure tool B
> will always find an operational socket handled by A? There is the
> obvious startup time required within A until it can service requests.
Keep in mind that "socket is operational" and "daemon is ready to service
requests" are two separate events. With regular services, the difference is
hard to notice. But in this example, you are using socket activation, and
making these events separate is the whole point of socket activation!
What happens if B runs and tries to acces /path while A is still
> starting up?
1) systemd will ensure that the socket is operational long before it starts
2) when /bin/B attempts to connect, the kernel will make it wait in the
3) when A.service starts, it will inherit the already-operational socket fd
4) when A finally enters its accept() loop, B's connection attempt will
(The same mechanism is used by inetd/xinetd in its 'wait' mode, as well as
> DescriptionA socket
This "Service=" setting is redundant.
> Description=B, a tool talking to A
Instead of this, use "Requires=A.socket" + "After=A.socket".
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the systemd-devel