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
_______________________________________________
luv-main mailing list
[email protected]
http://lists.luv.asn.au/listinfo/luv-main
