Description of problem: An upgrade of systemd (as part of a larger update of many packages) left a systemd process misbehaving and the dnf command hanging while executing a postinstall script that was attempting to communicate to a systemd socket. Version-Release number of selected component (if applicable): systemd-234.11.git5f8984e.fc27 How reproducible: Perform an 'dnf --refresh upgrade' where the set of packages to be updated includes systemd and either 'flatpak' or 'icedtea-web' or probably any other package which communicates with the systemd user instance during its postinstall scriptlet. Steps to Reproduce: 1. install older version of flatpak and systemd 2. perform 'dnf --refresh upgrade' 3. after systemd upgrade, the 'systemd --user' process is spinning with high CPU and processes that connect to /run/user/0/bus will hang Actual results: - The systemd --user process on the system is using high CPU. - The systemd process is logging the following message every second: Looping too fast. Throttling execution a little. - The dnf upgrade hangs, running a postinstall scriptlet for flatpak. (icedtea-web also exhibited a hang when running gconftool-2). execution of the dnf upgrade only continues when the systemd --user process is killed Expected results: systemd upgrade should leave the system in a workable state. Perhaps the 'systemd --user' instance for the root user should be restarted by the systemd postinstall. Additional info: workaround for users experiencing this issue, to allow the 'dnf upgrade' to continue without further hangs: - find the 'systemd --user' process and kill it
It appears from dnf history that the prior version of systemd, which was upgraded, was: systemd-234-10.git5f8984e.fc27.x86_64 Additionally I performed the same dnf upgrade on another system earlier in the day, it also upgraded the same older version of systemd, to the same newer version, and did not exhibit the problem described above. So it may have just been bad luck and not a regular occurrence.
Closing this as it didn't happen again in another upgrade, so seems to be situation-dependent, and unable to reproduce it again.
Thanks. Sorry for not looking into this.
See also [bug 1244342], which looks pretty similar, though no systemd (nor dbus nor polkit nor glibc, for that matter) got updated in the transaction, yet the results appear to be the same. FWIW, there's also likely less relevant, yet at least reproducible: https://github.com/systemd/systemd/issues/10627