Avery Payne wrote:
I suspect that you and Laurent would argue that I shouldn't be using sockets inside of ./run as it is, [...]
I don't really understand this whole explanation of your problem, at first blush. So I'm reserving any judgement. But ...
Avery Payne wrote:
If you have sequenced dependencies, can you truly gain a lot of time by attempting parallel startup? Is the gain for the effort really that important? Can we even speed things up when fsck is deemed mandatory by the admin for a given situation? Questions like these make me wonder if this is really a feasible feature at all.
The experience of Debian and Ubuntu was that far more was gained in startup time reduction by switching the shell used to run all of those scripts to the low-overhead Debian Almquist Shell from the Bourne Again Shell, than was gained with parallelism with upstart and startpar.
Startup time is not the be-all and end-all, of course, and an excessive focus upon it is detrimental. That said, the excessive delays in the /etc/rc.delay mechanism on PC-BSD were what motivated me to get BSD fully-nosh-service-manager-managed early on. It was delaying things on the order of a minute or more, and the things that it was delaying were things like setting the console screen size and keyboard layout, which aren't exactly wait-for-the-network items. Objectively, it might not belong as the first bullet point on the nosh blurb page. But from my personal point of view it most certainly did. (-:
So whilst there are microscopic things that are drowned out by the noise, there are also humungous whoppers, too.
The systemd dictum is that to truly take advantage of parallel startup, one eliminates orderings as far as possible. Which is where "socket activation" comes in. Part of "socket activation" is systemd opening server sockets early, and passing them to the server processes that get run. Because clients depend from the availability of the sockets, rather than from the availability of the final services, clients and servers can actually start in parallel, and the client is *not* declared as dependent from the *service* being up.
From a UCSPI perspective, this mechanism is of course what the UCSPI world has wanted from services all along: that they accept their listening, or their connected, sockets as already opened standard file descriptors. There's pressure on some of the more adamantly isolate softwares to "be socket activatable", which of course means that (with only a little bit of adjustment) they can also be plumbed into the UCSPI way of working. Ironically, it's the converse of the situation where pressure from the daemontools family world has led over the past couple of decades to all sorts of programs (especially on the BSDs) gaining -D or --don't-fork or --foreground or -F options, the benefit of which systemd is reaping.
Now, as I noted elsewhere, UCSPI hasn't been limited to one little family for some years. Even GNU inetd is in on the act, nowadays. This is because UCSPI defines a way for a server program to receive its already-open sockets and information about them. It doesn't get into anything beyond the interface between the server program and what is passing the sockets to it. So one big superserver, as inetd and systemd are, can adhere to the UCSPI protocols just as much as a decentralized system with lots of tcp-socket-listen/tcp-socket-accept or s6-tcpserver4-socketbinder/s6-tcpserver4d programs can. (GNU inetd does; systemd doesn't.) So don't get UCSPI mixed up with a scheme of service management.
Where UCSPI comes in is in run programs: the mechanics of the run program invoking tcp-socket-listen or s6-tcpserver4-socketbinder or tcpserver and those in turn invoking the service-providing program. Where it does not come in is service dependencies and ordering. "socket activation" includes that under its umbrella because in the systemd world sockets and the services that serve over them are two separate classes of entity, treated as things (units) that can be individually started/stopped/enabled/disabled. One starts a socket unit (auto-starts it at boot time if it is enabled) and the socket unit conceptually "activates" (i.e. starts) the related service unit, as and when. The daemontools family has different concepts and design. One starts services. It just so happens that some of them open sockets, listen, and then run stuff, either immediately or when something happens.
