The road forward for systemd

Posted May 26, 2010 22:37 UTC (Wed) by mezcalero (subscriber, #45103)
In reply to: The road forward for systemd by drag
Parent article: The road forward for systemd

yes this is what happens. basically everything will just work for you, from an app's perspective it makes no difference whether a service it wants to use is running, is being started or is not running yet. the app will see no difference, except maybe in the time a request is responded to.

The road forward for systemd

Posted May 26, 2010 22:56 UTC (Wed) by cesarb (subscriber, #6266) [Link] (2 responses)

It is more interesting to consider what would happen if the resolver were in a separate computer, and both computers were booted at the same time.

With systemd, the listening socket would become available very quickly in the computer with the resolver (limited mostly by the BIOS delay); that is, even between separate machines, it could help.

It would be even cooler if it were possible to have service dependencies across machines (so for instance machine A would delay loading a service until a listening socket in machine B becomes available). This would end the problem of having to figure out which machine you have to boot first when the power went out on your >300-day uptime servers.

The road forward for systemd

Posted May 26, 2010 23:54 UTC (Wed) by foom (subscriber, #14868) [Link] (1 responses)

Well....DNS maybe isn't a very good example here. Having a DNS socket *exist* isn't particularly useful. If it takes more than 5 seconds to respond, it might as well not bother responding at all, because the client will have given up. And, the resolver library on the client will retry at least once, so even without systemd opening the socket ahead of time, if the system manages to startup Bind in < 5sec, the retry will succeed and everyone will be happy.

The road forward for systemd

Posted May 27, 2010 19:50 UTC (Thu) by mgedmin (subscriber, #34497) [Link]

Clients usually wait 30 seconds for DNS timeouts.