Bug 2085481 - sysusers didn't get run for users defined in systemd-udev.rpm
Summary: sysusers didn't get run for users defined in systemd-udev.rpm
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 36
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-05-13 13:02 UTC by Lennart Poettering
Modified: 2022-11-20 01:34 UTC (History)
11 users (show)

Fixed In Version: systemd-251~rc3-1.fc37 systemd-249.13-6.fc35
Clone Of:
Environment:
Last Closed: 2022-05-17 16:13:45 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.