It seems some directory specification in the spec file are botched (e.g. missing /): Attempt to (re-)install lldpd gives the following error message: [...] Downloading Packages: lldpd-1.0.16-1.fc38.x86_64.rpm 14 MB/s | 201 kB 00:00 ------------------------------------------------------------------------------------------------------------------------------------------------------- Total 142 kB/s | 201 kB 00:01 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Running scriptlet: lldpd-1.0.16-1.fc38.x86_64 1/2 useradd: invalid home directory '%{_sharedstatedir}/lldpd' Reinstalling : lldpd-1.0.16-1.fc38.x86_64 1/2 warning: user lldpd does not exist - using root Running scriptlet: lldpd-1.0.16-1.fc38.x86_64 1/2 [...] Subsequently trying to start lldpd generates the following messages in the journal: Apr 19 21:03:26 fedora lldpd[849]: no lldpd user for privilege separation, please create it Apr 19 21:03:26 fedora systemd[1]: lldpd.service: Main process exited, code=exited, status=1/FAILURE Apr 19 21:03:26 fedora systemd[1]: lldpd.service: Failed with result 'exit-code'. Apr 19 21:03:26 fedora systemd[1]: Failed to start lldpd.service - LLDP daemon. After manually creating a user, starting lldpd fails with the following message in the journal: Apr 20 16:27:22 fedora lldpd[19427]: unable to create control socket at /runlldpd/lldpd.socket: Read-only file system Also, it seems directory tree /runlldpd/chroot is created. Adding "-u /run/lldpd/lldpd.socket" to lldpd's sysconfig file let's lldpd start, but now it complains in the log: Apr 20 16:29:17 fedora lldpd[19464]: unable to create /runlldpd/chroot/etc directory: Read-only file system I manually removed that directory so lldpd indeed cannot access it, but the directory name doesn't look right anyway, I guess it should have been /run/lldpd/chroot/... Looks like Reproducible: Always Steps to Reproduce: 1. dnf install lldpd 2. 3. Actual Results: Installation produces error messages. lldpd cannot be started successfully, the start job goes into retry loop and eventually gives up, with lldpd printing error messages to the log in the process. Expected Results: Installation procedure should not produce error messages. It should be possible to start lldpd successfully.
I guess the second part of the issues comes from missing "/"s in the build configuration section of the spec file: %build %configure --disable-static --with-snmp --disable-silent-rules \ --with-privsep-user=%{name} --with-privsep-group=%{name} \ --with-privsep-chroot=%{_rundir}%{name}/chroot \ <--- missing / before %{name} ? --with-lldpd-ctl-socket=%{_rundir}%{name}/%{name}.socket \ <--- missing / before the first %{name} ? --with-systemdsystemunitdir=%{_unitdir} --with-sysusersdir=no The resulting library has the wrong path built in: $ grep runlldpd /lib64/liblldpctl.so.4.9.1 grep: /lib64/liblldpctl.so.4.9.1: binary file matches
I also encountered this on Fedora37 while having lldpd installed. I had to downgrade the lldpd package then remove the junk runlldpd folder. [user@home ~]$ ls -lhaZ /runlldpd/ total 16K drwxr-xr-x. 1 root root system_u:object_r:default_t:s0 12 Apr 20 14:16 . dr-xr-xr-x. 1 root root system_u:object_r:root_t:s0 234 Apr 20 14:08 .. drwxr-xr-x. 1 root root system_u:object_r:default_t:s0 6 Apr 20 14:16 chroot [user@home ~]$ ls -lhaZ /run/lldpd/ total 0 drwxr-xr-x. 3 root root system_u:object_r:lldpad_var_run_t:s0 60 Apr 20 14:08 . drwxr-xr-x. 46 root root system_u:object_r:var_run_t:s0 1.3K Apr 20 14:10 .. drwxr-xr-x. 3 root root system_u:object_r:lldpad_var_run_t:s0 60 Apr 3 17:09 chroot Apr 20 14:09:36 home.user.local lldpd[1372601]: unable to create control socket at /runlldpd/lldpd.socket: Read-only file system Apr 20 14:09:36 home.user.local lldpd[1372601]: giving up Apr 20 14:09:36 home.user.local systemd[1]: lldpd.service: Main process exited, code=exited, status=1/FAILURE Apr 20 14:09:36 home.user.local systemd[1]: lldpd.service: Failed with result 'exit-code'. Apr 20 14:09:36 home.user.local systemd[1]: Failed to start lldpd.service - LLDP daemon. Apr 20 14:09:36 home.user.local systemd[1]: lldpd.service: Scheduled restart job, restart counter is at 5. Apr 20 14:09:36 home.user.local systemd[1]: Stopped lldpd.service - LLDP daemon. Apr 20 14:09:36 home.user.local systemd[1]: lldpd.service: Start request repeated too quickly. Apr 20 14:09:36 home.user.local systemd[1]: lldpd.service: Failed with result 'exit-code'. Apr 20 14:09:36 home.user.local systemd[1]: Failed to start lldpd.service - LLDP daemon.
The problem is that previously the lldpd spec-file specified its own "rundir" variable depending on if it was build to a systemd-enabled distro, or a legacy distro. With 1.0.16-1 it was changed to use an built in rpmmacro, however the old var included a "/" that the rpmmacro does not provide. https://src.fedoraproject.org/rpms/lldpd/pull-request/7 is compiled and run-time tested, and seems to fix the issue.
Hello Peter, Thanks for this update! Does that also fix the user creation issue? I.e. another macro name (%{_sharedstatedir}) was copied verbatim into lldpd-systemd-sysusers.conf (https://src.fedoraproject.org/rpms/lldpd/blob/rawhide/f/lldpd-systemd-sysusers.conf), and is still present in the scriplet that is included in the RPM file: $ rpm -qp --scripts lldpd-1.0.16-1.fc39.x86_64.rpm preinstall scriptlet (using /bin/sh): # generated from lldpd-systemd-sysusers.conf getent group 'lldpd' >/dev/null || groupadd -r 'lldpd' || : getent passwd 'lldpd' >/dev/null || \ useradd -r -g 'lldpd' -d '%{_sharedstatedir}/lldpd' -s '/sbin/nologin' -c 'Used by the lldpd daemon' 'lldpd' || : exit 0 [...] Execution of that scriplet fails with the first error message quoted in my original post. I am no expert, but I don't think these macros are intended to be expanded at install time. Rather, I'd expect for the macro to be expanded at build/packaging time, which at least with lldpd-1.0.16-1.fc39 apparently did not work as intended.
Hmm, no, as I did not hit this problem (probably because I already have a user created from earlier versions), and missed your post. It also seems like this package does not follow the guidelines for this as outlined in https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation The files is named wrong, and is missing the install line it should have. Also, looking at how lldpd works, I cannot see any real need for a set home directory, and as such maybe it should just be left empty in the sysuser file. Some fedora maintainer also actually needs to look into this and merge/fix the package. It seems like lldpd is a bit behind on maintenance.
FEDORA-2023-c9a3103c65 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c9a3103c65
FEDORA-2023-ecc18ce3f4 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ecc18ce3f4
FEDORA-2023-ed96524ef2 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed96524ef2
FEDORA-2023-c9a3103c65 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-c9a3103c65` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c9a3103c65 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ed96524ef2 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ed96524ef2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed96524ef2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ecc18ce3f4 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ecc18ce3f4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ecc18ce3f4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ecc18ce3f4 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-ed96524ef2 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-c9a3103c65 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.