The road forward for systemd

Posted May 26, 2010 19:12 UTC (Wed) by drag (guest, #31333)
In reply to: The road forward for systemd by Cyberax
Parent article: The road forward for systemd

> What are we going to do with network sockets and other services, for example? I have an application which bombs out if BIND is not yet started (it needs a resolver to resolve host names when it reads its config). How do I mark this dependency?

If my understanding is correct:

Presumably when a application requests something from BIND; it will get launched to serve that request.

Sooo... it would go something like this:

1 Application requests name resolution

2 Request goes through the nsswitch stuff. The nsswitch configuration indicates:
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

3. So the look up checks your hosts files, tries mdns4_minimal (which should trigger Avahi to start up) then finally ties the 'dns' method.

4. The /etc/resolv.conf file is checked. The resolv.conf has, as it's first entry:
nameserver 127.0.0.1

5a. The code then connects to UDP or TCP port 53 on localhost.

5b. The Systemd configuration method would have bind service conifigured and the systemd stuff will be listenning on port 53 in a inetd-like fashion.

6. Systemd responds to request on localhost port 53 and launches Bind.

Soooo.... To answer your question of:
>How do I mark this dependency?

You configure /etc/resolv.conf to have localhost as a nameserver.

The road forward for systemd

Posted May 26, 2010 22:37 UTC (Wed) by mezcalero (subscriber, #45103) [Link] (3 responses)

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.

The road forward for systemd

Posted May 27, 2010 10:32 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

So, systemd should listen on UDP 53 (I don't have Avahi, BTW)? Can you point out where the blog post says something about _network_ services? Can it even be done correctly?

Also, what if I want to listen only on a few interfaces (LAN interface and localhost) - are we going to completely replicate inetd (which I have gladly exterminated from my systems) there?

The road forward for systemd

Posted May 27, 2010 15:27 UTC (Thu) by drag (guest, #31333) [Link]

> So, systemd should listen on UDP 53

Thats the idea, I suppose.

> (I don't have Avahi, BTW)?

You should. It kicks ass. I've long stopped given a shit about static IP configurations and mucking around with DNS on my network because of it. Services like DAAP are cool.

> Can you point out where the blog post says something about _network_ services? Can it even be done correctly?

OK:
> 2. socket: this unit encapsulates a socket in the file-system or on the Internet. We currently support AF_INET, AF_INET6, AF_UNIX sockets of the types stream, datagram, and sequential packet. We also support classic FIFOs as transport. Each socket unit has a matching service unit, that is started if the first connection comes in on the socket or FIFO. Example nscd.socket starts nscd.service on an incoming connection.

So AF_INET == Network Socket for IPv4
So AF_INET6 == Network Socket for IPv6

> Also, what if I want to listen only on a few interfaces (LAN interface and localhost) -

No clue. Apparently for things to work optimally the services need to be patched so that they can take care of those sort of details themselves.

Probably with 'dumb' non-systemd optimized services you'll have to edit Systemd configs a little bit.

> are we going to completely replicate inetd (which I have gladly exterminated from my systems) there?

Sounds like it. Hope so. I like things to be simple.

The road forward for systemd

Posted May 31, 2010 16:56 UTC (Mon) by mezcalero (subscriber, #45103) [Link]

Yes, systemd is configured to listen on UDP 53 and then hand off the socket to the real bind.

And, as mentioned we create automatic dependencies between sockets and network interface devices if you for example configure a socket to bind to one particular interface only. That for example is another thing inetd cannot do for you, because it handles only sockets and nothing else. We track and control the entire system state, and hence can easily cover this, too.