On Wed, 03 Jul 2024 22:58:33 +0100 Luca Boccassi <bl...@debian.org>
wrote:
> On Wed, 3 Jul 2024 21:26:36 +0200 Michael Biebl <bi...@debian.org>
> wrote:
> > Am 03.07.24 um 21:00 schrieb Lionel Élie Mamane:
> > > On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:
> > >
> > >>>>> connect(5, {sa_family=AF_UNIX,
> sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1
> ECONNREFUSED (Connection refused)
> > >
> > >> systemd should be listening on this socket
> > >
> > > Well, on no less than four different Debian machines, it does
not.
> > >
> > >> $ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
> > >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE
NAME
> > >> systemd 1 root 28u unix 0x0000000073ac41e2 0t0 8696
> > >> /run/systemd/userdb/io.systemd.DynamicUser type=STREAM (LISTEN)
> > >
> > > Isn't that on a machine where systemd-userdb is installed maybe?
> The
> > > installation of that package triggers the systemd binary to
listen?
> >
> > No, systemd-userdb is not installed and as you can see from the
above
> > output it's actually systemd which listens on that socket.
>
> I can reproduce it by mounting a tmpfs on /run/systemd/userdb/ _and_
> creating an empty io.systemd.DynamicUser file on it. Maybe it should
> not abort like that, however, if you have the directory in /run/
_and_
> the socket file exists _but_ nothing is listening on it, then your
> machine is broken in some way. If the directory/socket are missing
they
> are just skipped gracefully.I'm not sure what's the alternative here - if consulting NSS fails for some local reasons because the machine is broken/misconfigured, I am not sure if it should just ignore it and continue it. If NSS is configured and is supposed to work, but doesn't for some temporary/local reason, you might end up creating a duplicated user/group, and I am not really sure that's better than bailing out without touching anything. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
