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: Unexpected behaviour you saw

As pointed out in #6484 (comment)

systemctl rescue will stop e.g. printer.target, and systemctl default will not start it again.

Equally, if you boot into rescue.target. printer.target will be started according to hardware availability, but systemctl default will stop it again.

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

If coming out of rescue mode will leave parts of the system in an unexpected state (similar to how Debian did not support switching back from runlevel 1), then rescue mode should not encourage / default to systemctl default (isolate default.target) on exit. reboot is fine.

I suppose systemctl default can be used if you booted to emergency.target. Although systemctl start default.target should also work, because sysinit.target has Conflicts=emergency.service emergency.target. We could effectively deprecate it?

Um. Also we don't seem to allow "starting individual units in order to continue the boot process in steps". As soon as you hit systemd-udev-trigger, you start printer.target, cups pulls in sysinit.target, emergency.service is stopped, your shell is killed, and you can't do anything. Not even ctrl+alt+del (because the VT is dealloced?).

In case of bug report: Steps to reproduce the problem

1. boot to default.target
2. systemctl status sound.target printer.target bluetooth.target
3. systemctl rescue
4. exit (ctrl+D)
5. systemctl status sound.target printer.target bluetooth.target