units: don't kill the emergency shell when sysinit.target is triggered (#6765)

Why
---

The advantage of this is that starting sysinit.target from the emergency
shell will no longer kill the emergency shell and lock you out of the
system.  Our docs already claimed that emergency.target was useful for
"starting individual units in order to continue the boot process in steps".
This resolves #6509 for my purposes.

Remaining limitation
--------------------

Starting getty.target will still kill the shell, and if you don't have a
root password you will then be locked out at that point.  This is relevant
to distributions which patch the sulogin system to permit logins when the
root password is locked.  Both Debian and RedHat used to follow this
behaviour!  Debian have been discussing what they could replace it with at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806852

So this doesn't quite achieve perfection, but I think it's a worthwhile
change.  It should be easier to understand the logic now it doesn't have
such a big hole in it.  Repairing the sysinit stage of the boot is the main
reason we have emergency.target.  And as discussed in the issue,
sysinit.target gets pulled in implicitly as soon as any DefaultDependencies
service is activated.

How
---

sysinit.target only needs to conflict with emergency.target.  It didn't
need to conflict with emergency.service as well.  In theory the conflicts
are pointless, we could just change the dependency of sysinit.target on
local-fs.target from Wants to Requires.  However, doing so would mean that
when local-fs fails, the screen is flooded with yellow [DEPEND] failures.
That would hinder the poor unfortunate admin, so let's not do that.

There is no additional ordering requirement against emergency.  If the
failure happens, the job for sysinit will be cancelled instantly.  We don't
need to worry about when sysinit.target and its dependents would be
stopped, because sysinit waits for local-fs before it starts.

emergency.target is still necessarily stopped once we reach sysinit
(you can't express a one-way conflict in pure unit directives).
This is largely cosmetic... though perhaps it symbolizes that you're no
longer in Emergency Mode if System Initialization is successful ;-).

As a secondary advantage, the getty's which conflict on rescue.service now
need to conflict on emergency.service as well.  This makes the system more
uniform and simpler to understand.

The only other effect this should have is that
`systemctl start emergency.target` is now practically the same as
`systemctl start rescue.target`.  The only units this command will stop are
the conflicting getty units.  Neither of those commands should ever be
used.  E.g. they will not stop the gdm.service unit on Fedora 26.

1 files changed, 2 insertions, 2 deletions

diff --git a/units/getty@.service.m4 b/units/getty@.service.m4
index ff1b3c3d87..c2665e3f6b 100644
--- a/units/getty@.service.m4
+++ b/units/getty@.service.m4
@@ -23,8 +23,8 @@ IgnoreOnIsolate=yes
 # IgnoreOnIsolate causes issues with sulogin, if someone isolates
 # rescue.target or starts rescue.service from multi-user.target or
 # graphical.target.
-Conflicts=rescue.service
-Before=rescue.service
+Conflicts=rescue.service emergency.service
+Before=rescue.service emergency.service
 
 # On systems without virtual consoles, don't start any getty. Note
 # that serial gettys are covered by serial-getty@.service, not this