bug#52533: guix deploy breaks SSH access with a PAM error

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Ludovic!

Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> 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.

I personally still think the idea is more than "okay"; I see value in
it; one of the obvious benefits is documentation; most GNU packages come
with Texinfo documentation, which makes for a nice, integrated
experience.  I also think that as the system becomes more established
and integrate more of GNU, more GNU packages maintainers may be
interested in joining and contributing (reaching some critical mass).

> 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.

If we keep it dumb and use inetd, it wouldn't, right?  From what I
understand, systemd uses socket activation as a means to chain events,
while inetd is typically used to delay a service starting to save on
resources such as RAM (for services seldom used).  Is my primitive
understanding about right?

> 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.

At a heavy cost (complexity -- sheer amount of code).  I remember
finding out, for example, that the database-backed, compressed logging
of systemd would consume more disk space than an uncompressed text log
file.  That's because each message has multiple keys associated with
that needs to be written to disk.  It's surprisingly inefficient.

>>> (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.

This sounds good to me, if you are confident it can fix the problem at
hand.

Thank you,

Maxim