Why do you think systemd is defendable for this? The prior init system had a means by which individual init scripts could be disabled during boot. I can't run systemd-analyze when the system off in lala-land for 5+ minutes. Moreover, if I know what is wrong, why can't I just cancel the job it's waiting for like I could previously from the console? It is a unacceptably bad user interface experience. There is no excuse for it. Again, this worked previously - why was this functionality lost / hidden? It's this "punch the user in the face" style of user interface design that I object to that is so prevalent in the corner cases of modern UIs.

A service has been configured that to say that it won't start until the network is up. Another target, your user interface has said it depends on the previously named service.

What is the correct action for systemd to take here? After a timeout it will do what you said it will do, but until then it will try to do what the configs have said it should do.

You can tweak this however you want. You can shorten the timeout to whatever you want, you can change the dependency graph so that particular unit does not depend on the network, you can disable it completely.

> It's this "punch the user in the face" style of user interface design that I object to that is so prevalent in the corner cases of modern UIs.

I don't understand what you mean here, it was configured to do one thing, and it did that thing. You can of course say that it's a bad config (which is probably true), but then it's either the distro, the packager, systemd's defaults (which often are not ideal) or your own customizations. I'm all for arguing about better defaults in systemd and making distros better config their packages, but the actual systemd init seems to have done exactly what it was told to do here. Again, I'd like to say that distros/packages/users of systemd treat it like a pure init and often don't use it as intended.

> I can't run systemd-analyze when the system off in lala-land for 5+ minutes.

If the tree of critical services for your boot are that broken I'd assume you need to boot into single user mode or use a recovery usb. But if you actually boot after those 5min I'd expect you to easily find where those 5mins where lost using the tools I mentioned above, which is more than I can say for previous inits.

Why does login on a console terminal depend on networking being up? It's a false dependency, one decided upon by the developer of systemd. And it was a poor choice. The mindset that "it's configurable" is inexcusably lame. That mantra allows bad developers to get away with not putting in the work of thinking about and understanding how users experience their software. It also allows rewrite-the-world projects to take off and throw out all the knowledge that is implicitly present in an existing system before having understood why that complexity came to exist in the first place.

Those who do not try to understand history are doomed to repeat it. That has clearly happened in the case of systemd and is why I don't think the attitude it presents towards end users is at the level that such a core piece of infrastructure should display.

I'm guessing it wasn't the systemd developers that configured it as such, but without seeing your dependency graph and knowing your distro and installed packages I don't know.

Maybe your distro supports LDAP or another remote user directory? Maybe you just have some services installed that depend on the network and that say they are critical to the multi-user.target? You haven't given enough info for me to know, but it probably isn't systemd's fault in this case.

The distro I use is developed by the company that employs the primary systemd developer. Do you really expect me to believe your assertion that he holds no responsibility for how systemd is shipped by that distribution?

Well, if you used the tools I mentioned you'd know who/what configured your system that way and how to fix it.