On Wed, 19 Aug 2015, Chris Samuel wrote:
On Tue, 18 Aug 2015 10:45:32 PM Brian May wrote:
Looking at /var/lib/dpkg/info/systemd.postinst I would speculate the trigger being called is after /etc/init.d is updated, it calls "systemctl daemon-reload" via a wrapper that checks /run/systemd/system exists first.
The only time I have seen this happen myself is when systemd was already broken, because the kernel was too old and didn't have the required features.
Possibly nothing wrong with the kernel here, however I have to wonder if systemd was already broken for some reason. Maybe it failed to start up correctly because something else was broken.
Or X had already hosed the system, and then when systemd was told to reread config files it got blocked on device IO.
Difficult to tell without something like dmesg output to see whether things had already gone bung by this stage and an alt-sysrq-w dump to list the state of tasks that are in uninterruptible state ('D').
Filesystem (root NFS) was definitely OK. Only things stuck were systemd and virtual console stuff. systemd-getty-generator would have been stuck because console was stuck. From there, somehow init ended up waiting for a kernel lock. -- Tim Connors