Hi, Maxim Cournoyer <[email protected]> skribis:
> Ludovic Courtès <[email protected]> writes: > > [...] > >> sshd could also be started via socket activation; ‘sshd’ subprocesses >> corresponding to existing logins would be unaffected. >> >>> Also, it seems to me inetd can already do "socket activation", if this >>> was somehow useful. >> >> Yes, inetd can do that. It would be nicer though to have it all >> integrated in the Shepherd. > > I'm not sure. The beauty of Shepherd, in my eyes, when compared to > other init systems, is that it is lean and clean. Leveraging what's > already out there (and part of GNU) seems an obvious path to me, as it: > > 1. Means less code to write, document and maintain. > 2. Creates more cohesion between various components of the GNU project. Heheh, Guix was started to address #2 actually. Today, I think #2 is okay but should not be an obstacle. As for #1, sure, but Shepherd will need to grow a proper event loop anyway, so socket activation won’t make much of a difference. Also, taking a step back, systemd undoubtedly changed user expectations for the better in terms of integration, monitoring, and logging. Having the same level of integration in the Shepherd would be a step in that direction. >> (Basically, it’s a choice we could make right away: do we move all >> network daemons, plus things like guix-daemon, dbus-daemon, etc. etc. to >> inetd services, or do we instead extend the Shepherd to support socket >> activation? I’m rather in favor of the latter, but if in Guix System we >> build an abstraction that can equally well target inetd or a future >> Shepherd version, that’s even better.) > > We could start with just targeting inetd, and build the abstraction > later, if the need arises, perhaps? We may never need it. Yes, so what I had in mind is, in Guix System, something like <socket-activated-service>, which would kinda look like <shepherd-service> but be lowered (for now) to an inetd service. Thanks, Ludo’.
