shadow.service complains about users managed by systemd-homed.

mys_721tx · 2022-12-06 17:31:13

On my box (systemd 252.2-3, linux 6.0.11.arch1-1, shadow 4.12.3-2), shadow.service recently complains about users managed by systemd-homed are missing from /etc/group:

# systemctl status shadow.service
× shadow.service - Verify integrity of password and group files
     Loaded: loaded (/usr/lib/systemd/system/shadow.service; static)
     Active: failed (Result: exit-code) since Tue 2022-12-06 00:03:59 PST; 9h ago
   Duration: 52ms
TriggeredBy: ● shadow.timer
    Process: 25807 ExecStart=/bin/sh -c /usr/bin/pwck -r || r=1; /usr/bin/grpck -r && exit $r (code=exited, status=2)
   Main PID: 25807 (code=exited, status=2)
        CPU: 51ms

Dec 06 00:03:59 claw sh[25810]: delete member 'mys_721tx'? No
Dec 06 00:03:59 claw sh[25810]: shadow group users: no user mys_721tx
Dec 06 00:03:59 claw sh[25810]: delete member 'mys_721tx'? No
Dec 06 00:03:59 claw sh[25810]: shadow group audio: no user mys_721tx
Dec 06 00:03:59 claw sh[25810]: delete member 'mys_721tx'? No
Dec 06 00:03:59 claw sh[25810]: shadow group wheel: no user mys_721tx
Dec 06 00:03:59 claw sh[25810]: delete member 'mys_721tx'? No
Dec 06 00:03:59 claw sh[25810]: grpck: no changes
Dec 06 00:03:59 claw systemd[1]: shadow.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Dec 06 00:03:59 claw systemd[1]: shadow.service: Failed with result 'exit-code'.

Meanwhile:

# homectl inspect mys_721tx
   User name: mys_721tx
       State: active
 Disposition: regular
 Last Change: Mon 2022-12-05 22:42:20 PST
 Last Passw.: Sat 2022-05-07 09:25:41 PDT
    Login OK: yes
 Password OK: yes
         UID: 60091
         GID: 60091 (mys_721tx)
 Aux. Groups: vboxusers
              wireshark
              realtime
              users
              audio
              wheel
   Directory: /home/mys_721tx
     Storage: luks (strong encryption)
  Image Path: /home/mys_721tx.home
   Removable: no
       Shell: /bin/zsh
 Access Mode: 0700
LUKS Discard: online=yes offline=yes
   LUKS UUID: 1949...
   Part UUID: f558...
     FS UUID: c5ea...
 File System: btrfs
 LUKS Cipher: aes
 Cipher Mode: xts-plain64
  Volume Key: 256bit
 Mount Flags: nosuid nodev exec
   Disk Size: 500.0G
  Disk Usage: 377.5G (= 75.6%)
   Disk Free: 122.4G (= 24.4%)
  Disk Floor: 377.5G
Disk Ceiling: 1.6T
  Good Auth.: 731
   Last Good: Tue 2022-12-06 07:51:47 PST
   Bad Auth.: 977
    Last Bad: Tue 2022-12-06 07:51:46 PST
    Next Try: anytime
 Auth. Limit: 30 attempts per 1min
   Rebalance: off
SSH Pub. Key: 2
   Passwords: 1
  Local Sig.: yes
     Service: io.systemd.Home

Running pwck and grpck by themselves give no error:

# pwck -r
# grpck -r

Googling "shadow.service" and "systemd-homed" has not been fruitful. Has anyone encounter a similar situation?

cfr · 2022-12-06 19:32:56

Welcome to the forums.

I'm still managing users and groups the old-fashioned way, but I thought the idea of the systemd management was that regular users would not be listed in /etc/passwd, /etc/shadow and similarly for private groups in /etc/groups etc.? Do you still have that user listed in those files?

E.g. https://systemd.io/CONVERTING_TO_HOMED/ is linked from the wiki and instructs you to remove users from those files prior to conversion.

mys_721tx · 2022-12-06 19:48:16

Thanks cfr! I indeed followed the migration guide and removed the regular users and their corresponding private groups from /etc/passwd, /etc/groups, and their shadow counterpart. Since the guide only mentioned the private groups, I did not touch any auxiliary groups in /etc/groups.

cfr · 2022-12-06 23:20:14

Just from reading, I think that's right because systemd will only manage the private groups. (And you often want non-regular users in other groups as well, anyway.)

It would somewhat make sense if grpck didn't know about users managed by systemd, but I don't know why you'd get different results running it manually ....

loqs · 2022-12-09 04:12:58

https://github.com/shadow-maint/shadow/ … pck.c#L390 should be the failing call. getpwnam uses nsswitch and the systemd-homed users should be provided by nss-systemd. So some unknown condition needs to be satisfied for nss-systemd to return a record?

mys_721tx · 2022-12-09 04:27:05

And the /etc/nsswitch.conf hasn't been modified at all.

# cat /etc/nsswitch.conf
# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.

passwd: files systemd
group: files [SUCCESS=merge] systemd
shadow: files systemd
gshadow: files systemd

publickey: files

hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

I tried adding [SUCCESS=merge] to gshadow and shadow.service still fails.

loqs · 2022-12-09 05:31:44

What if you explicitly enabled systemd-userdbd.service

mys_721tx · 2022-12-09 05:44:30

systemd-userdbd.service has already been enabled and running.

# systemctl enable systemd-userdbd.service
# systemctl disable systemd-userdbd.service
Removed "/etc/systemd/system/sockets.target.wants/systemd-userdbd.socket".
# systemctl enable systemd-userdbd.service
Created symlink /etc/systemd/system/sockets.target.wants/systemd-userdbd.socket → /usr/lib/systemd/system/systemd-userdbd.socket.

cfr · 2022-12-09 15:11:54

mys_721tx wrote:

And the /etc/nsswitch.conf hasn't been modified at all.

Isn't this the problem?

NSS-SYSTEMD(8) wrote:

To activate the NSS module, add "systemd" to the lines starting with "passwd:", "group:", "shadow:" and "gshadow:" in /etc/nsswitch.conf.
It is recommended to place "systemd" after the "files" or "compat" entry of the /etc/nsswitch.conf lines so that /etc/passwd, /etc/group, /etc/shadow and /etc/gshadow based mappings take precedence.

mys_721tx · 2022-12-09 16:01:19

No, what I meant is that /etc/nsswitch.conf is as shipped in filesystem 2022.10.18-1 with systemd already added.

loqs · 2022-12-09 16:17:49

I was wondering if the socket based activation of systemd-userdbd was not being used by nss-systemd. If the journal shows systemd-userdbd was started before shadow.service failed then I am out of ideas.

mys_721tx · 2022-12-09 16:25:00

Looks like systemd-userdbd started before shadow.service.

Dec 08 20:23:18 claw audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=unconfined msg='unit=systemd-userdbd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
...
Dec 08 20:23:45 claw audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=unconfined msg='unit=shadow comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Since this started to look like a bug, I'll see where to file a report.

cfr · 2022-12-09 17:02:11

mys_721tx wrote:

No, what I meant is that /etc/nsswitch.conf is as shipped in filesystem 2022.10.18-1 with systemd already added.

Sorry, don't know how I missed that.

Arch Linux

#1 2022-12-06 17:31:13

shadow.service complains about users managed by systemd-homed.

#2 2022-12-06 19:32:56

Re: shadow.service complains about users managed by systemd-homed.

#3 2022-12-06 19:48:16

Re: shadow.service complains about users managed by systemd-homed.

#4 2022-12-06 23:20:14

Re: shadow.service complains about users managed by systemd-homed.

#5 2022-12-09 04:12:58

Re: shadow.service complains about users managed by systemd-homed.

#6 2022-12-09 04:27:05

Re: shadow.service complains about users managed by systemd-homed.

#7 2022-12-09 05:31:44

Re: shadow.service complains about users managed by systemd-homed.

#8 2022-12-09 05:44:30

Re: shadow.service complains about users managed by systemd-homed.

#9 2022-12-09 15:11:54

Re: shadow.service complains about users managed by systemd-homed.

#10 2022-12-09 16:01:19

Re: shadow.service complains about users managed by systemd-homed.

#11 2022-12-09 16:17:49

Re: shadow.service complains about users managed by systemd-homed.

#12 2022-12-09 16:25:00

Re: shadow.service complains about users managed by systemd-homed.

#13 2022-12-09 17:02:11

Re: shadow.service complains about users managed by systemd-homed.

Board footer