RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1793527 - systemd sends tons of useless PropertiesChanged messages when a mount happens [rhel-7.9.z]
Summary: systemd sends tons of useless PropertiesChanged messages when a mount happens...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.7
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Michal Sekletar
QA Contact: Frantisek Sumsal
Depends On: 1793533
Blocks: 1801675 1917516 1920502
TreeView+ depends on / blocked
Reported: 2020-01-21 14:15 UTC by Renaud Métrich
Modified: 2021-01-26 12:31 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1917516 1920502 (view as bug list)
Last Closed: 2020-11-10 12:58:04 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github systemd-rhel rhel-7 pull 119 0 None closed (#1793527) Don't emit PropertiesChanged signal needlessly 2021-02-17 06:29:44 UTC
Github systemd systemd pull 15233 0 None closed device: make sure we don't generate bogus PropertiesChanged signals 2021-02-17 06:29:44 UTC
Red Hat Product Errata RHBA-2020:5007 0 None None None 2020-11-10 12:58:17 UTC

Description Renaud Métrich 2020-01-21 14:15:28 UTC
Description of problem:

This is kinda a continuation of BZ #1769928, this time focused on optimizing DBus messages being sent.
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:


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:


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.

Comment 11 Lukáš Nykrýn 2020-08-11 16:02:59 UTC
fix merged to github rhel-7.9 branch -> https://github.com/systemd-rhel/rhel-7/pull/119

Comment 52 errata-xmlrpc 2020-11-10 12:58:04 UTC
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 (systemd 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.


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