The followup from the following (this) morning is worth reading as well. In summary: nothing conclusive, but hints that something may be hanging on NFS I/O after networking has been taken down.
Well that’s interesting, I have a similar problem on my Fedora desktop. Rebooting the system will shutdown X, bring up the console screen and just sit there with no messages at all, just the cursor blinking at position (0,0). I’ll have the reboot manually. This is very frustrating.
I’m a complete outsider to systemd but from what I’ve read here on Lobste.rs, it seems like an excellent case study in the dangers of software rewrites. It highlights that there is a lot of complexity hidden away in the details of the code, and thus rewrites are followed by a long tail of bug reports and complaints about missing functionality. If the cause of this bug is something to do with NFS, then surely it’s something that’s been dealt with previously.
Bear in mind that often much of what you’ll see about anything, systemd included, is complaints; people write less praise for things for various reasons, and such praise often gets less publicity than juicy bad news like this. I say this as the original entry’s author and someone who has written about, eg, things that systemd gets right and my overall views on systemd, to go along with the various bad things I’ve written about systemd (this latest annoyance included).
The specific NFS issue involved here is not a trivial one to solve and past solutions in other init systems have had their own fragilities, where they might do things like kill necessary daemons too early because the init system didn’t know you had an unusual configuration. In one sense systemd appears to be doing exactly what it was told to do, and part of the issue is that Ubuntu created an overall configuration where they didn’t make sure that everything would happen in the right order. Systemd could do better but a reasonably general solution would require some policy decisions and possibly significantly more work.