[Solved]Controlling systemd's 'emergency-behaviour'

hungerfish · 2014-08-15 14:54:50

So after boot-cycling some systems only to return to the 'emergency-console' because something went wrong during boot, I'm wondering if there is any way to control 'when' exactly the system(d) decides it can no longer continue booting.
More specifically, I know why the boot fails, its because of a certain mount line in /etc/fstab.
Sometimes the filesystem just isn't available, in my case because the kernel-module needed hasn't been rebuilt after a kernel upgrade, but its easy to image other scenarios like networked filesystems and such.

So I'm wondering how to stop systemd from dropping into 'emergency-room-mode' just because of a failed mount line in /etc/fstb, and more generally if/where/how more fine grained control is possible.

Any ideas?

Last edited by hungerfish (2014-08-17 13:32:05)

falconindy · 2014-08-15 15:00:59

hungerfish wrote:

So I'm wondering how to stop systemd from dropping into 'emergency-room-mode' just because of a failed mount line in /etc/fstb, and more generally if/where/how more fine grained control is possible.

"just because" is an odd way to look at this problem. fstab is static filesystem configuration. If a device might not be available at boot time, then you need to use 'nofail' and 'noauto' flags to tell systemd not to care about that device. Since you seem to want this to be dynamic, you might further consider adding 'x-systemd.automount' to the options, as this will cause the filesystem to be mounted on first access.

hungerfish · 2014-08-15 15:38:59

Thanks for the reply. just minutes after posting, I read a bug report somewhere which mentioned 'x-systemd.automount' option of which I've previously never heard of.
Maybe that will work. In my case, the device IS available, just not usable, because of a missing module (only sometimes after kernel upgrades).
That's the reason I still consider my setup static (I only mentioned the net-stuff because it seemed related) and I find it odd that systemd does not seem to discriminate between errors.

So my specific problem may be fixed, but what about the more general question? Is this behaviour, the 'reaction to errors' so to speak customizable somehow?

falconindy · 2014-08-15 16:04:41

hungerfish wrote:

the device IS available, just not usable, because of a missing module

You're splitting hairs. The device isn't available to the kernel and, therefore, isn't available to you either.

hungerfish wrote:

So my specific problem may be fixed, but what about the more general question? Is this behaviour, the 'reaction to errors' so to speak customizable somehow?

Not really. You boot towards a given target (usually default.target) and all dependencies must be satisfied along the way. If this fails to hold true, then systemd has no choice but to bail out.

For specific units, you can use OnFailure, but I'm not sure how to interacts with the initial transaction at bootup or how you could possibly apply this in any dynamic way. Very likely, you'll still end up at the crash shell.

Last edited by falconindy (2014-08-15 16:06:25)

alphaniner · 2014-08-15 16:14:49

falconindy wrote:

... 'nofail' and 'noauto' ...

Maybe it's bad practice, but I use just 'nofail' for all non-essential entries in fstab. IMO my headless server failing to boot because /mnt/foobar can't be mounted is just ridiculous.

falconindy · 2014-08-15 16:41:56

alphaniner wrote:

falconindy wrote:
... 'nofail' and 'noauto' ...
Maybe it's bad practice, but I use just 'nofail' for all non-essential entries in fstab. IMO my headless server failing to boot because /mnt/foobar can't be mounted is just ridiculous.

Putting dynamic mounts in a static configuration file seems more ridiculous. Note that your server wouldn't have booted under sysvinit, either, because 'mount -a' would fail and drop you to a shell on the missing device.

hungerfish · 2014-08-15 18:00:08

Putting dynamic mounts in a static configuration file seems more ridiculous.

Where else to put them? Seriously, I have no idea...

...failing to boot because /mnt/foobar can't be mounted is just ridiculous.

I also think that this 'could be handled better, more gracefully'. I mean, it may be correct not to put 'dynamic stuff' in fstab, but dropping to a root shell is harsh, imagine windows booting nogui or safemode because it can't find an usb-drive or some such..

If this fails to hold true, then systemd has no choice but to bail out.

Why can't it just 'ignore' some stuff? Surely it would be possible to rewrite those 'target/rules' to make this more flexible?
Lastly, this thread is not about the systemd vs. sysvinit debate, I've long accepted my fate

alphaniner · 2014-08-15 18:55:51

falconindy wrote:

Putting dynamic mounts in a static configuration file seems more ridiculous. Note that your server wouldn't have booted under sysvinit, either, because 'mount -a' would fail and drop you to a shell on the missing device.

The mounts I 'nofail' aren't intended to be dynamic, though I suppose they could be. From my perspective they're just not [otherwise] necessary to reach default.target or such. The default behaviour makes sense, but for my purposes I'd rather the boot process be as permissive as possible. And that's exactly the effect 'nofail' seems to have.

Trilby · 2014-08-15 19:01:53

hungerfish wrote:

... imagine windows booting ...

No thanks.

hungerfish wrote:

Why can't it just 'ignore' some stuff?

So you want to give your computer rules to follow, but it can ignore some of them. And it gets to chose when to stick to the rules and when to ignore some, and it gets to chose which ones to ignore.

Ok, now I am imagining windows' booting.

falconindy · 2014-08-15 21:48:54

hungerfish wrote:

Why can't it just 'ignore' some stuff? Surely it would be possible to rewrite those 'target/rules' to make this more flexible?

How does it know what to ignore? Hrmmm, here's an idea -- you can tell systemd not to bother waiting on the device to show up (nofail), and not to wait for the filesystem to be mounted (noauto). What's the problem, again?

hungerfish · 2014-08-17 13:31:48

...but for my purposes I'd rather the boot process be as permissive as possible.

Exactly my point, it could be more permissive in case such as non-essential fs not being available.*
The 'nofail' option apparently does just that (tell the system that a fs is not essential). This fixes my 'problem'.

And it gets to chose when to stick to the rules and when to ignore some, and it gets to chose which ones to ignore.

The whole point of me asking was to find out how to to instruct the system towards behaving in a appropriate fashion. The 'nofail' option tells the system to 'ignore some stuff', in this case a filesystem, I don't get your angle.

What's the problem, again?

*While using 'nofail' works fine, the 'problem/nag' that remains is that this could be the default for non-essential mountpoints thus eliminating the need for adding the option manually. But I guess there's a ton of reasons for it not being so, or maybe not...

Arch Linux

#1 2014-08-15 14:54:50

[Solved]Controlling systemd's 'emergency-behaviour'

#2 2014-08-15 15:00:59

Re: [Solved]Controlling systemd's 'emergency-behaviour'

#3 2014-08-15 15:38:59

Re: [Solved]Controlling systemd's 'emergency-behaviour'

#4 2014-08-15 16:04:41

Re: [Solved]Controlling systemd's 'emergency-behaviour'

#5 2014-08-15 16:14:49

Re: [Solved]Controlling systemd's 'emergency-behaviour'

#6 2014-08-15 16:41:56

Re: [Solved]Controlling systemd's 'emergency-behaviour'

#7 2014-08-15 18:00:08

Re: [Solved]Controlling systemd's 'emergency-behaviour'

#8 2014-08-15 18:55:51

Re: [Solved]Controlling systemd's 'emergency-behaviour'

#9 2014-08-15 19:01:53

Re: [Solved]Controlling systemd's 'emergency-behaviour'

#10 2014-08-15 21:48:54

Re: [Solved]Controlling systemd's 'emergency-behaviour'

#11 2014-08-17 13:31:48

Re: [Solved]Controlling systemd's 'emergency-behaviour'

Board footer