On Wed, 03 Jul 2024 23:10:30 +0100 Luca Boccassi <bl...@debian.org> wrote: > 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.
Consensus seems to be that in this bad situation it's slightly better to complain loudly and continue, so the next point release will contain a fix to this effect. You should still figure out how you ended up with a dead af_unix socket in the first place, as that's a sign of something seriously wrong on that machine. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part