http://bugzilla.opensuse.org/show_bug.cgi?id=958346 http://bugzilla.opensuse.org/show_bug.cgi?id=958346#c1 --- Comment #1 from Robin Roth --- The behaviour looks similar like the one after https://bugzilla.opensuse.org/show_bug.cgi?id=918226. daemon-reload and daemon-reexec also don't work (time out...) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=958346 http://bugzilla.opensuse.org/show_bug.cgi?id=958346#c3 --- Comment #3 from Robin Roth --- Thanks for the hints. Since looking into the issue we have log-level=debug as well as some custom monitoring on all machines and try to catch one that fails "in-the-act". There is no pattern to the machines failing, desktops of different hardware, a server. We now have a machine on 13.2 with the same symptoms. One thing that is common to all machines is a custom service running that has an underscore in it's name. CoreOS had a bug, but that's code that is as far as I understand is not present in openSuSE (https://github.com/coreos/fleet/issues/579) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=958346 http://bugzilla.opensuse.org/show_bug.cgi?id=958346#c5 Howard Guo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hguo@suse.com --- Comment #5 from Howard Guo --- Hello Robin. I have got similar failures more consistently on a different hardware platform. I have several servers running on KVM, the ones with severely capped IO throughout can easily reproduce the issue: 1. Cap the IO throughout to about 5MB/s 2. Enable swap file (increase demand for IO throughout) 3. Create heavy IO congestion by launching an IO and memory intensive operation, it must be small enough not to trigger OOM but large enough to evict almost all file cache. The system load climbs to 20 for a single CPU system. 4. Issue a systemctl command such as stopping a unit, while the above operation is in progress, observe a timeout due to heavy system load. 5. Stop the IO congestion and wait several seconds, then reissue the systemctl command. There is a good chance of timeout and all further systemctl commands always timeout. While I do not know enough about systemd to understand what went wrong, but I could work around it by running the operation in a systemd unit file with very low IO and CPU scheduling priority. I'm curious to know, what sort of workload do the machines run ? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=958346 http://bugzilla.opensuse.org/show_bug.cgi?id=958346#c7 Robin Roth changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |UPSTREAM --- Comment #7 from Robin Roth --- As discussed in https://github.com/systemd/systemd/issues/2200#issuecomment-168606293 the issue was a rather complex timer setup. While it shouldn't crash systemd it's easily avoidable. Also I am still not able to get a reproducible setup that immediately crashes systemd. Therefore this can be closed (in my opinion). -- You are receiving this mail because: You are on the CC list for the bug.