Discussion:
emergency vs. rescue
(too old to reply)
Bill Nottingham
2010-09-03 19:30:50 UTC
Permalink
Is there any real, useful, reason to define both of these? In RH/Fedora, we
don't support a distinction, and haven't since switching away from sysvinit.
As they're set up now in systemd, they're identical except for some string
output, and do not have any different handling in the daemon itself aside
from the different arguments. It seems far simpler to define one and worry
about adding more later rather than creating a reserved word/signal/target
that will live forever that may not be necessary.

Bill
Lennart Poettering
2010-09-05 17:43:23 UTC
Permalink
Post by Bill Nottingham
Is there any real, useful, reason to define both of these? In RH/Fedora, we
don't support a distinction, and haven't since switching away from sysvinit.
As they're set up now in systemd, they're identical except for some string
output, and do not have any different handling in the daemon itself aside
from the different arguments. It seems far simpler to define one and worry
about adding more later rather than creating a reserved word/signal/target
that will live forever that may not be necessary.
In systemd, "emergency" is little more than an equivalent to
init=/bin/sh on the kernel command like. i.e. you get a shell, but
almost nothing else (except for systemd in the background which you can
then ask to do more). No services are started, no mount points mounted,
no sockets established, nothing. Just a raw, delicious shell and
systemd's promise to be around if you need more. In contrast to that
"rescue" is equivalent to the old runlevel 1 (or S), i.e. sysinit is
run, everything is mounted, but no normal services are started yet.

I think emergency mode is kinda nice for debugging purposes, since it
allows you to boot bit-by-bit, simply by starting in the emergency mode
and then starting the various services and other units that are part of
the early boot step-by-step. This will become particularly useful when
Fedora splits up sysinit into various smaller scripts which could then
be started seperately and independently.

Consider it a part of our boot-up debugging tools.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Bill Nottingham
2010-09-07 16:09:22 UTC
Permalink
Post by Lennart Poettering
In systemd, "emergency" is little more than an equivalent to
init=/bin/sh on the kernel command like. i.e. you get a shell
Not as it's currently configured. sysinit.service has
'Before' on it. Is that not intentional?

Bill
Lennart Poettering
2010-09-07 16:25:49 UTC
Permalink
Post by Bill Nottingham
Post by Lennart Poettering
In systemd, "emergency" is little more than an equivalent to
init=/bin/sh on the kernel command like. i.e. you get a shell
Not as it's currently configured. sysinit.service has
'Before' on it. Is that not intentional?
It is intentional. This i added to make sure that the emergency shell is
gone before sysinit is started, in case the user boots into the
emergency shell and then types "systemctl default" or "systemctl
rescue" to bring up a bigger part of the system.

Note that After/Before not only control the startup order but also the
shutdown order.

The rules go like this:

1. If between a unit A and B neither After nor Before is defined their
start or stop may be fully parallized in all thinkable ways.

2. If A has a Before dep on B, and two jobs are scheduled for the two
units, being either "start" or "stop", then the following ordering
table is followed:

| A/start | A/stop
--------+------------------------------|-----------------------------
B/start | A/start first, B/start second| A/stop first, B/start second
--------+------------------------------+-----------------------------
B/stop | B/stop first, A/start second | B/stop first, A/stop second

Where "A/start" means "A shall be started". The inner fields of the
table will tell you the execution order of the jobs, and the headers
tell you the jobs that are scheduled.

3. If A has an After dep on B, then because After is the inverse of
Before, B will have a Before dep on A, and the inverse of the table
from #2 applies.

Note the assymmetry: if two units have an ordering dep between them,
and one shall be stopped and the other started, then the stopping
happens first the start second, regardless wheher After or Before is
used!

And I hope this is not too confusing...

Lennart
--
Lennart Poettering - Red Hat, Inc.
Bill Nottingham
2010-09-07 16:41:54 UTC
Permalink
Post by Lennart Poettering
And I hope this is not too confusing...
It reads confusingly, in that if sysinit is 'Before' emergency, the
implication would be that if you enable emergency mode, sysinit would be
started before it. It isn't, as the dependency isn't there.

Two other emergency points:
- it doesn't have the same sort of boot alias as 'single'. If you're
going for compat with old sysvinit, it should have an 'emergency' alias
(that leaves out systemd.unit=....)
- respawn is pretty pointless here (as it is for rescue). It should
just have ExecStartPost=/bin/systemctl default

Bill
Lennart Poettering
2010-09-07 16:53:29 UTC
Permalink
Post by Bill Nottingham
Post by Lennart Poettering
And I hope this is not too confusing...
It reads confusingly, in that if sysinit is 'Before' emergency, the
implication would be that if you enable emergency mode, sysinit would be
started before it. It isn't, as the dependency isn't there.
sysinit.target has a Conflicts with emergency.target.
Post by Bill Nottingham
- it doesn't have the same sort of boot alias as 'single'. If you're
going for compat with old sysvinit, it should have an 'emergency' alias
(that leaves out systemd.unit=....)
Hmm, not sure I follow? This emergency mode didn't really exist in
sysv.

Are you asking for a simpler way to boot into it? Simpler than passing
"systemd.unit=emergency.target" at the kernel cmdline?
Post by Bill Nottingham
- respawn is pretty pointless here (as it is for rescue). It should
just have ExecStartPost=/bin/systemctl default
Hmm, you have a point there. I need to think about this.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Bill Nottingham
2010-09-07 17:18:55 UTC
Permalink
Post by Lennart Poettering
Post by Bill Nottingham
It reads confusingly, in that if sysinit is 'Before' emergency, the
implication would be that if you enable emergency mode, sysinit would be
started before it. It isn't, as the dependency isn't there.
sysinit.target has a Conflicts with emergency.target.
Not currently in the packages here; sysinit only conflicts with shutdown.
Post by Lennart Poettering
Post by Bill Nottingham
- it doesn't have the same sort of boot alias as 'single'. If you're
going for compat with old sysvinit, it should have an 'emergency' alias
(that leaves out systemd.unit=....)
Hmm, not sure I follow? This emergency mode didn't really exist in
sysv.
If sysvinit is passed 'emergency' on the command line, it starts a shell.
(This is all done in init itself, not inittab or other configuration.)
Post by Lennart Poettering
Are you asking for a simpler way to boot into it? Simpler than passing
"systemd.unit=emergency.target" at the kernel cmdline?
Right, much like 'single' starts the rescue mode, 'emergency' should
start this mode.
Post by Lennart Poettering
Post by Bill Nottingham
- respawn is pretty pointless here (as it is for rescue). It should
just have ExecStartPost=/bin/systemctl default
Hmm, you have a point there. I need to think about this.
That line works fine for rescue mode in testing... it should work OK for
emergency mode (as long as it's started during boot and not later - perhaps
emergency should have RefuseManualStart=yes?)

Bill
Lennart Poettering
2010-09-08 10:38:45 UTC
Permalink
Post by Bill Nottingham
Post by Lennart Poettering
Post by Bill Nottingham
It reads confusingly, in that if sysinit is 'Before' emergency, the
implication would be that if you enable emergency mode, sysinit would be
started before it. It isn't, as the dependency isn't there.
sysinit.target has a Conflicts with emergency.target.
Not currently in the packages here; sysinit only conflicts with shutdown.
Oh. Uh. By bit means of "isolate" it gains that....
Post by Bill Nottingham
Post by Lennart Poettering
Post by Bill Nottingham
- it doesn't have the same sort of boot alias as 'single'. If you're
going for compat with old sysvinit, it should have an 'emergency' alias
(that leaves out systemd.unit=....)
Hmm, not sure I follow? This emergency mode didn't really exist in
sysv.
If sysvinit is passed 'emergency' on the command line, it starts a shell.
(This is all done in init itself, not inittab or other configuration.)
Oh, I wasn't aware of that. I have now added this to systemd git. Thanks
for the pointer.
Post by Bill Nottingham
Post by Lennart Poettering
Post by Bill Nottingham
- respawn is pretty pointless here (as it is for rescue). It should
just have ExecStartPost=/bin/systemctl default
Hmm, you have a point there. I need to think about this.
That line works fine for rescue mode in testing... it should work OK for
emergency mode (as long as it's started during boot and not later - perhaps
emergency should have RefuseManualStart=yes?)
Hmm, my long term plan is to make the boot scripts fully idempotent so
that we can execute them twice in a row and they work fine. I think they
mostly work fine that way already with the exception of fsck which fails
when executed a second time because the file systems might be mounted or
mounted writable.

Lennart
--
Lennart Poettering - Red Hat, Inc.
Continue reading on narkive:
Loading...