Bugzilla – Bug 1165294
haveged is marked as deleted after reboot
Last modified: 2024-07-12 09:48:09 UTC
Hi, *After reboot*, a couple of my TW systems show: $ zyp ps Verbosity: 2 Checking for running processes using deleted libraries... The following running processes use deleted files: PID | PPID | UID | User | Command | Service | Files ----+------+-----+------+-------------------+--------- +------------------------------ 531 | 1 | 0 | root | haveged (deleted) | haveged | /lib64/ld-2.31.so | | | | | | /lib64/libc-2.31.so | | | | | | /usr/sbin/haveged (deleted) | | | | | | /usr/lib64/libhavege.so.1.1.0 You may wish to restart these processes. See 'man zypper' for information about the meaning of values in the above table. No core libraries or services have been updated. Reboot is probably not necessary. Marcus Meissner noted on the factory ML, that: > It is ran in the initrd and probably still running after transition to the > regular system. > > (Likely pulled in via dracut-fips module) Shouldn't a transition from initrd to regular operation include a restart of this service then?
Haveged ships its own module. I just checked and it _should_ even restart correctly on pivot_root, at least in the version available in the staging repo. Reassigning to havaged maintainer for further investigation.
Hello, I've just recently noticed the same on my installation of Tumbleweed. I've rebooted, force reinstalled haveged and rebooted again. sudo zypper -vvv ps Verbosity: 3 Checking for running processes using deleted libraries... The following running processes use deleted files: PID | PPID | UID | User | Command | Service | Files ----+------+-----+------+-------------------+---------+------------------------------ 193 | 1 | 0 | root | haveged (deleted) | haveged | /usr/lib64/libhavege.so.2.0.0 | | | | | | /lib64/ld-2.32.so | | | | | | /lib64/libc-2.32.so | | | | | | /usr/sbin/haveged (deleted) sudo zypper -vvv needs-rebooting Verbosity: 3 No core libraries or services have been updated. Reboot is probably not necessary. Note: I just restarted the service as the log was automatically rotated just after reboot and the status info said it may be incomplete. ian@Naga:~/ > sudo systemctl status haveged ● haveged.service - Entropy Daemon based on the HAVEGE algorithm Loaded: loaded (/usr/lib/systemd/system/haveged.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2020-10-08 23:48:02 BST; 35s ago Docs: man:haveged(8) http://www.issihosts.com/haveged/ Main PID: 5900 (haveged) Tasks: 1 (limit: 4915) Memory: 3.6M CGroup: /system.slice/haveged.service └─5900 /usr/sbin/haveged -w 1024 -v 0 -F Oct 08 23:48:02 Naga systemd[1]: Started Entropy Daemon based on the HAVEGE algorithm. Oct 08 23:48:02 Naga haveged[5900]: haveged: command socket is listening at fd 3 Please let me know if you require any more info.
While this is from the cosmetics department, it's good for surprises for the attentive user: when a finished zypper dup states, that updated processes are still running, if you have previously checked that no such packages are affected... So it would be nice if somebody could take care of it.
Hans, can you try to reproduce it with latest haveged? I've updated it to version 1.9.17 and I'm unable to reproduce it. If this issue persists, I will take care of this bug.
Hi Otto, sorry, forgotten about this report. Yes, I can confirm, this issue vanished a long time ago already. Let's close it for good.
This still does not work on vms using VirtIO disk instead of SCSI disk: # zypper ps The following running processes use deleted files: PID | PPID | UID | User | Command | Service | Files ----+------+-----+------+-------------------+---------+------------------------------ 177 | 1 | 0 | root | haveged (deleted) | haveged | /lib64/ld-2.31.so | | | | | | /usr/lib64/libhavege.so.2.0.0 | | | | | | /lib64/libc-2.31.so | | | | | | /usr/sbin/haveged (deleted) You may wish to restart these processes. See 'man zypper' for information about the meaning of values in the above table. No core libraries or services have been updated since the last system boot. Reboot is probably not necessary. # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sr0 11:0 1 1024M 0 rom vda 253:0 0 32G 0 disk ├─vda1 253:1 0 8M 0 part ├─vda2 253:2 0 19,8G 0 part /tmp │ /var │ /usr/local │ /root │ /opt │ /srv │ /boot/grub2/i386-pc │ /boot/grub2/x86_64-efi │ /.snapshots │ / ├─vda3 253:3 0 10,2G 0 part /home └─vda4 253:4 0 2G 0 part [SWAP] The problem is on Tumbleweed and Leap 15.4 vms with VirtIO disk. haveged is not restarted after root is mounted: # journalctl _SYSTEMD_UNIT=haveged.service Dez 21 01:23:43 localhost haveged[177]: haveged: command socket is listening at fd 3 On a vm using SCSI disk, it is restarted: # journalctl _SYSTEMD_UNIT=haveged.service Dez 21 01:24:43 wpyc057 haveged[172]: haveged: command socket is listening at fd 3 Dez 21 01:24:49 wpyc057 haveged[172]: haveged: Stopping due to signal 15 Dez 21 01:24:49 wpyc057 haveged[172]: haveged starting up Dez 21 01:24:49 wpyc057 haveged[620]: haveged: command socket is listening at fd 3
> On a vm using SCSI disk, it is restarted And it has the same kernel version? At least on Tumbleweed haveged-switch-root.service has `ConditionKernelVersion=<5.6`
(In reply to Andrei Borzenkov from comment #8) > > On a vm using SCSI disk, it is restarted > > And it has the same kernel version? > > At least on Tumbleweed haveged-switch-root.service has > > `ConditionKernelVersion=<5.6` Sorry. Both vms are Leap 15.4. Tumbleweed vm with VirtIO disk also does not restart haveged.service I dont have a TW vm with SCSI disk yet.
(In reply to Andrei Borzenkov from comment #8) > > On a vm using SCSI disk, it is restarted > > And it has the same kernel version? > > At least on Tumbleweed haveged-switch-root.service has > > `ConditionKernelVersion=<5.6` Now that's strange: haveged on Tumbleweed seems to behave now (since Dec 16) correctly: -- Boot c264891fbbf042c88d079e34c9b05586 -- Dec 16 04:29:58 localhost haveged[190]: haveged: command socket is listening at fd 3 Dec 16 04:30:03 localhost haveged[542]: haveged: command socket is listening at fd 3 -- Boot 1acffdefb8644f48bd1a1e10921dd5cc -- Dec 21 01:23:43 localhost haveged[190]: haveged: command socket is listening at fd 3 Dec 21 01:23:52 localhost haveged[554]: haveged: command socket is listening at fd 3 So I will close again.
(In reply to Andreas Vetter from comment #10) > (In reply to Andrei Borzenkov from comment #8) > > > On a vm using SCSI disk, it is restarted > > > > And it has the same kernel version? > > > > At least on Tumbleweed haveged-switch-root.service has > > > > `ConditionKernelVersion=<5.6` > > Now that's strange: > haveged on Tumbleweed seems to behave now (since Dec 16) correctly: > -- Boot c264891fbbf042c88d079e34c9b05586 -- > Dec 16 04:29:58 localhost haveged[190]: haveged: command socket is listening > at fd 3 > Dec 16 04:30:03 localhost haveged[542]: haveged: command socket is listening > at fd 3 > -- Boot 1acffdefb8644f48bd1a1e10921dd5cc -- > Dec 21 01:23:43 localhost haveged[190]: haveged: command socket is listening > at fd 3 > Dec 21 01:23:52 localhost haveged[554]: haveged: command socket is listening > at fd 3 > > So I will close again. and I believe, that Otto Hollmanns recent changes fix a few additional corner cases in this regard. It was a fun ride to get there, even it is mostly cosmetic, and the kernel guys try hard to phase this package out anyway..
This still occurs on Leap 15.4 with a current kernel 5.14.21-150400.24.46-default #1 SMP PREEMPT_DYNAMIC Thu Feb 9 08:38:18 UTC 2023 (2d95137) x86_64 The following running processes use deleted files: PID | PPID | UID | User | Command | Service | Files ----+------+-----+------+-------------------+---------+------------------------------ 976 | 1 | 0 | root | haveged (deleted) | haveged | /lib64/ld-2.31.so | | | | | | /usr/lib64/libhavege.so.2.0.0 | | | | | | /lib64/libc-2.31.so | | | | | | /usr/sbin/haveged (deleted) # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 1.8T 0 disk ├─sda1 8:1 0 97M 0 part ├─sda2 8:2 0 40G 0 part ├─sda3 8:3 0 1G 0 part │ └─cr_boot 254:0 0 1022M 0 crypt /boot ├─sda4 8:4 0 1K 0 part ├─sda5 8:5 0 500G 0 part │ └─cr_lvmsys 254:1 0 500G 0 crypt │ ├─lvmsys-swap 254:2 0 10G 0 lvm [SWAP] │ ├─lvmsys-root 254:3 0 80G 0 lvm / │ └─lvmsys-home 254:4 0 200G 0 lvm /home Or is the fix only intended for past-15.4?
Responding to c#12 I'm not seeing that. I checked two systems running 15.4, and neither of them shows "haveged" as deleted.