This bug was initially created as a copy of Bug #1793527
I am copying this bug because:
Also applies to RHEL 8.1
Description of problem:
It appears that a single "mount" operation on a single file system (including a "mount -o remount") makes systemd send 2 PropertiesChanged message per mount point seen on the system (even if the mount point is not touched).
This creates a huge systemd load, and potentially a huge load on DBus.
The root cause behind this is an absence of caching of the /proc/1/mountinfo table.
Version-Release number of selected component (if applicable):
systemd-219 AND systemd-239 (RHEL8)
How reproducible:
Always
Steps to Reproduce:
1. Set up a system with 200 mount points on a "data" volume group
# vgcreate data /dev/sdb
# for i in $(seq 1 200); do lvcreate -n lv$i -L 10M data; mkfs.ext4 /dev/data/lv$i; echo "/dev/mapper/data-lv$i /data/lv$i ext4 defaults 0 0" >> /etc/fstab; mkdir -p /data/lv$i; done
# systemctl daemon-reload
# mount -a
2. Monitor systemd's "sendmsg" while performing 100 remounts of /data/lv1
In a terminal:
# timeout 1m strace -ttTvyy -o /tmp/systemd.strace -s 1024 -e sendmsg -p 1
In another terminal:
# for i in $(seq 1 100); do mount -o remount /data/lv1; sleep 0.1; done
3. Count the number of PropertiesChanged messages sent
# grep -c PropertiesChanged /tmp/systemd.strace
Actual results:
40600
Expected results:
100 (ideally) or 200 (observed with a patch because there is a PropertiesChanged message for "/" seen, holding "/data/lv1")
Additional info:
The load is due to systemd parsing the whole /proc/1/mountinfo table and UDEV database to construct "description" field of corresponding Device units, requiring tons of malloc().
Finally all this gets sent through DBus "blindly" (no one cares about these messages).
A simple optimization (count dropping to 200) is to only send data when "description" field changes.
A better optimization would be to cache the content of /proc/1/mountinfo and only recompute the "description" field based on UDEV database for the modified mount points, but it's harder to do.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Low: systemd security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2020:4553
(In reply to jdee from comment #46)
> Was this Systemd patch ported to CoreOS 4.8?
Fix for this bug was delivered in RHEL-8.4. CoreOS 4.8 is based on RHEL-8.4 EUS hence it should contain this bugfix.