You are not logged in.
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?
Offline
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.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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.
Offline
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 ....
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
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?
Offline
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.
Offline
What if you explicitly enabled systemd-userdbd.service
Offline
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.
Offline
And the /etc/nsswitch.conf hasn't been modified at all.
Isn't this the problem?
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.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
No, what I meant is that /etc/nsswitch.conf is as shipped in filesystem 2022.10.18-1 with systemd already added.
Offline
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.
Offline
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.
Offline
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.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline