On Wed, Dec 10, 2014 at 11:32 AM, Olaf Hering o...@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
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
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 graw...@gmail.com
systemd-devel mailing list