Submission type

• Bug report

systemd version the issue has been seen with

systemd-233-6.fc26.x86_64

Used distribution

Fedora 26

In case of bug report: Expected behaviour you didn't see

…

In case of bug report: Unexpected behaviour you saw

Every other use of rescue.target involves isolating it.

rescue.target does not really appear to be designed to be started, e.g. by following the instruction in the Install section and linking it to kbrequest.target.

1. It does appear to successfully hijack the current VT and run sulogin.
2. It looks like switching to a different VT (at least while the password prompt is shown) stops rescue.target again. Dunno what that's about.
3. If you allow sulogin to exit, without being stopped by systemd, rescue.target then triggers systemctl default.

That last does not seem to make sense in this case. If you've isolated a non-default target T, starting rescue.target doesn't stop T, but then exiting from the sulogin does (and systemctl stop rescue.target) does not.

It doesn't make sense on a default Fedora Desktop boot either, because systemctl isolate graphical.target seems to be treated as a request to kill any GUI sessions.

In case of bug report: Steps to reproduce the problem

From a VT, run systemctl enable rescue.target. Then press Alt+Up. sulogin appears, but if you switch to other VTs, you can see your other getty's and GUI programs have not been stopped. If instead of switching, you press Ctrl+D to cancel sulogin, then you see the effects of systemctl default, stopping any graphical sessions you started. This does not really make sense.