I am not very familiar with systemd. The answer I seek with this question is:

How is it possible to make systemd react to problems with "dropping the user into an emergency shell of sorts", instead of simply having an unresponsive system?

Example for being explicit: Case of an install of arch linux on a thinkpad, it seems that there is some miscofiguration of the x-org-server, or wayland, or maybe systemd, or lightdm, which instead of producing a error message leaves the user hung up. This means that the user sees the service/startup messages being output to tty1 come to stop, without any having any error message produced (if there is one the glorious systemd-journald ate it??) and no key combination whatsoever can even produced a root shell to enable the user to check for the error and correct it.

Consequenlty the answer how to configure systemd to drop into a emergency shell to avoid a hung up system at any error, on the way to a graphical.target

How such a hung up situation might be like is done for instance in this U&L question "arch-linux-hang-on-reached-target-graphical-interface"

  • If you can't switch to another VT (CTRL+ALT+F?), then you're not going to be able to get a shell. This commonly happens when the graphics card isn't initialized properly. Usually you need to tune/switch the driver. – Patrick Jun 12 '18 at 16:09

There is no part of the systemd configuration which includes having an unresponsive system as an intentional path.

Systemd does have lots of configuration devoted to process management. See for example Restart= and OnFailure=.

To solve your problem and avoid the unresponsive sytem, you are going to have better understand what the cause is. Checking journalctl -xe is a good starting point (possibly after a reboot). Try searching for "fatal" or "error" in the output.

If you have a kernel panic or corrupt memory, systemd is not going to be able to help you in any case.


The emergency.target can be triggered when an unit enters failed state by using OnFailure=emergency.target in the [Unit] section. That said, a service "hanging" (busy looping forever) will not trigger a failure condition, it will keep going until killed or timeout reached.

Systemd can't know if the program that "hangs" is doing what is designed to do or is failing, it is up to the system administrator to decide that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.