What were you trying to do that didn't work?

On systems with many units, e.g. this was seen with a system having 358 disks and 14288 "device" units, issuing a systemctl daemon-reload makes systemd become not responsive for a very long time, similar to what is seen with systemctl list-unit-files on smaller systems.
This leads to not being able to monitor services using {{ systemctl status ...}} command because it fails in timeout.
The issue occurs especially after issuing a systemctl enable ... command, which internally executes daemon-reload.

Troubleshooting this, it was found that most of the time was spent sending update messages for the many units back to systemctl daemon-reload and DBus clients (such as systemd --user instances).
For example, in customer's case, the reload (under strace) took 2min25 and 286240 DBus messages were sent in total to the 4 existing DBus clients (one fourth each).

What is the impact of this issue to you?

Having systemd be unresponsive is problematic for administering the system

Please provide the package NVR for which the bug is seen:

systemd-239-82.el8_10.1

How reproducible is this bug?:

Always on customer systems