3 ms·
Socket activation is nice for certain things, like webservers. Unfortunately for other services socket activation can cause you far more headaches. For instance
by cyphar 8y ago
Socket activation is nice for certain things, like webservers. Unfortunately for other services socket activation can cause you far more headaches. For instance, Docker's default configuration used to be socket activated under systemd -- this was changed because it meant on-reboot that you wouldn't have any containers running until someone tried to do an administrative command (that used docker.sock).
Socket activation is more meant to allow for on-demand starting of services without losing connections -- and the design shows that this is the main purpose. For many services, "having a connection" doesn't mean the service is ready yet.
I think that having a notification system for a service to tell the init system it is ready would be nice, though the "obvious" way of doing it (rt signals) wouldn't work for unprivileged services.
- bonzini 8y agoThe systemd notification system uses sockets. See https://www.freedesktop.org/software/systemd/man/sd_notify.html https://www.freedesktop.org/software/systemd/man/sd_notify.h... It looks like it has grown a bit since the last time I saw the manpage...
- Too 8y agoSystemd can wait for dbus services to be fully ready instead of just process start. Iirc there is also a way to use the watchdog apis for this if you have other types of ipc than dbus.
- Spivak 8y agoBut in systemd there's no reason you can't have a service enabled on boot and socket activation. It's a little redundant but it can be good to catch some corner cases: like you can always issue docker commands even if Docker isn't ready.