Am 08.02.21 um 14:52 schrieb Uoti Urpala:
On Mon, 2021-02-08 at 11:27 +0100, Reindl Harald wrote:
this is *not* what systemd-sockets are for
they are for service is started at the first connect
This is wrong. Socket units are useful completely independently of
whether the unit is started on demand, and it's a good idea to use them
even for services that are always started on boot. They allow
configuring listening ports in a consistent manner, and make it
possible to avoid direct dependencies between services. The latter
pretty much avoids all further issues with ordering: once you've
started all the sockets, you can freely start all the services in
parallel or in whatever order - a depended-on service process starting
later is never a problem, since requests will just get queued in the
socket and will work fine once the service is fully up. In principle,
you could even have two services which both require the other, as long
as the exact requests they make will not result in a deadlock. In
almost any setup at least the improved parallelism improves performance
at boot or when otherwise starting services.
that's all nice but when you want what the OP wnats it makes no sense
and as long as my machines are boot in 3-12 seconds added complexity
needs to find a problem to solve
the point is: when your configuration can't handle sockets or you can't
handle them just don't use them for the sake of using them with no
measureable benefit
it can't boot fast enough to compensate all the "fuck it i said stop the
service" of the past 10 years and as long systemd is not smart enough
that "systemctl stop x" stops both, the service and the socket unit that
makes no fun at all
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
