systemd errs on the safe side and thus it tries really hard to shut things down safely vs just yanking the plug. The timeouts are easily configurable if that's a problem for you, but I'd argue that if services hang too often for you, there's an underlying problem with your system somewhere, (i.e. your mounts or such, I'd consult journald for dependency cycles).
There might be some way in which I had run a system that caused those endless slowdowns.
But the point is, and that's why I think systemd is garbage, that there is nothing there that helps me debug what is going on. If the shutdown is hanging there is nothing to do except the reset button or waiting for an eventual reboot. In neither case will there be any forensics about what exactly systemd had tried to do and how it thought that it failed.
That is the part that is not acceptable.
P.S. I shouldn't have to manually adjust a timeout on disabling swapspace on shutdown to prevent a need for a reboot by reset button. The kind of thinking that got big timeouts into those things is precisely why I say that systemd people just think differently than I do.
> that there is nothing there that helps me debug what is going on
That's not really true. Journald is your friend. I find many of the complaints about systemd stem from unfamiliarity with its tools.
The Arch Wiki gives a really nice overview of the most common usage scenarios[1] & [2], that's worth investing some time into. Also [3] is your friend. Just refusing to put any time into learning systemd and then complaining about it, is one approach, but not a particularly productive one.
In your case, I'd try something like `systemd-analyze verify default.target` and go from there.
Additionally, look into /etc/system.d/system.conf, specifically adjusting the Timeout values to a less conservative value.
