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