Hey, I've been reading through the documentation on systemd and the Mailing List Archives and have had some questions, so I figured I'd post them here. These might be fairly complicated or unusual cases, and there may be no good answers now, and maybe no good answers ever, but I'd still like to get an idea of what you think.<div>
<br></div><div>First up, parallel startup using sockets.</div><div><br></div><div>We know that the theory of this goes something like this: you have a service that many other services and processes depend on, and connect to via a socket. Rather than manually express that dependency in the configuration, you instead have the socket created by the init daemon in advance. Now you simply start the service and all of the other services and processes together, and let the blocking nature of those sockets (or the software polling a non-blocking socket) sort out the ordering for you.</div>
<div><br></div><div>This seems to assume that it's a free cost to start a service or process and have it block on a socket. But that isn't true, to get to the point where it connects to the socket, that service or process first has to be loaded from disk, its shared libraries mapped and relocated, it probably has to do a bunch of initialization including reading its own configuration files, etc.</div>
<div><br></div><div>That's fine for "low priority" services out of the critical path for user interaction, but not for services we need as fast as possible.</div><div><br></div><div>The best example I can think is the X server itself. It's pretty much the definition of the critical path. Everything started before the X server are those basic system components needed to start the X server, I understand in systemd that this core part would be a different target to the X part and a dep of it. Everything started after the X server is up are components of the user's session that aren't totally critical for them to login or use their computer.</div>
<div><br></div><div>It's during the X startup that things get interesting. There are a few discreet phases of it.</div><div><br></div><div>Firstly we have to spawn the X server, load the executable, map and relocate shared libraries, all of that jazz. You don't want anything else happening on the system alongside this, and you most certainly don't want every X client (Chromium/Firefox!) being loaded at the same time. The default behaviour of systemd seems to be to do just this :-(</div>
<div><br></div><div>Secondly you have the period after the X server has "loaded" while it initializes but before it's "ready" to receive clients. In a perfect world this would be fast, but we all know that it isn't. In practice the X server takes countable seconds to do this work. This is a prime place in boot optimization to start other services alongside while X does its thang. But you wouldn't want to flood the system, as you don't want to delay X's startup, just use the spare resource to get more done. Can systemd discern "X has been spawned" and "X has initialized". Can systemd serialize services in this period (perhaps limited to one or two starting at a time)? Can it prioritize the order of those services in the X target?</div>
<div><br></div><div>Lastly there's the processes you'd start after X is up and services are connecting to it; again I assume this would be a different target - how would systemd know that X, and the critical X services/processes are fully up and that it can begin starting these. The important thing here is user latency - the startup of these services need to not noticeably impact system performance - not as simple as prioritization because the service itself may well need a different priority once its up. Any thoughts here?</div>
<div><br></div><div>Thanks,</div><div><br></div><div>Scott</div>