Bug 2085481

Summary:	sysusers didn't get run for users defined in systemd-udev.rpm
Product:	[Fedora] Fedora	Reporter:	Lennart Poettering <lpoetter>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	36	CC:	fedoraproject, filbranden, flepied, lnykryn, msekleta, ryncsn, ssahani, s, systemd-maint, yuwatana, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	systemd-251~rc3-1.fc37 systemd-249.13-6.fc35	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-17 16:13:45 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Lennart Poettering 2022-05-13 13:02:34 UTC

Something's fishy with the sysusers hookup in RPM.

I installed a fresh fedora 36 the other day, on my laptop. And the systemd-timesync user never got created.

The boot-time service systemd-sysusers.service was conditioned out because of its ConditionNeedsUpdate=/etc logic. It requires that /usr/ is touched once on each update, but that didn't take place (it used to happen in the scriptlets once upon a time, but maybe that got lost? or wasn't replicated when systemd.rpm got split?)

And apparently systemd-sysusers wasn't invoked by the scriptlets directly either, which doesn't look right.

Normally, one of the two ways how systemd-sysusers is run should have create the users for me, but neither did.

A manual invocation then fixed things for me.

But nonetheless there are probably two things to fix here...

Comment 1 Zbigniew Jędrzejewski-Szmek 2022-05-16 13:13:17 UTC

Hmm, do you have any reference for this? I *do* remember that we talked about this in the past,
but I can't find any evidence of /usr being touched.

$ for i in $(git log --pretty='format:%H'); do git show "$i:systemd.spec"; done| rg touch | rg -v '^Patch|buildroot|^-' | sort -u
fatal: path 'systemd.spec' exists on disk, but not in '0d9e15b5c19d9b9b8843c69f67f6a93d90fc6753'
touch /etc/systemd/dont-synthesize-nobody
touch %{_localstatedir}/lib/rpm-state/systemd/needs-reload

(I filtered out patches, anything about %buildroot, and changelog entries. I assume
that touch would be the command do touch files.)

https://github.com/systemd/systemd/commit/94e75a5409 does this in the upstream installation
procedure, but that doesn't do anything for the rpm.

Comment 2 Zbigniew Jędrzejewski-Szmek 2022-05-16 18:21:04 UTC

https://github.com/systemd/systemd/pull/23404

Comment 3 Fedora Update System 2022-11-04 18:22:39 UTC

FEDORA-2022-8ac4104a02 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-8ac4104a02

Comment 4 Fedora Update System 2022-11-05 17:54:17 UTC

FEDORA-2022-8ac4104a02 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-8ac4104a02`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8ac4104a02

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 5 Fedora Update System 2022-11-20 01:34:31 UTC

FEDORA-2022-8ac4104a02 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.