Bug 56492

Summary:	OnFailure and JobTimeoutSec for default.target
Product:	systemd	Reporter:	Oleksii Shevchuk <public.avatar>
Component:	general	Assignee:	systemd-bugs
Status:	RESOLVED FIXED	QA Contact:	systemd-bugs
Severity:	enhancement
Priority:	high	CC:	radek
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	boot-watchdog.service boot-watchdog.target

Description Oleksii Shevchuk 2012-10-28 13:44:28 UTC

In case of misconfiguration there is possibility of "hanged" systemd boot. I.e. targets with login shell will never be reached. Most regular problem is mistakes in /etc/fstab or other FS stuff, and miscoded scripts. For my configuration I add OnFailure=emergency.target and JobTimeoutSec=60 to default.target. So in any case something with login prompt/console will be reached. Maybe default.target from systemd package should had something like this by default?

Comment 1 Oleksii Shevchuk 2012-11-01 17:42:08 UTC

Created attachment 69398 [details]
boot-watchdog.service

As for now i use this combination

Comment 2 Oleksii Shevchuk 2012-11-01 17:42:24 UTC

Created attachment 69399 [details]
boot-watchdog.target

Comment 3 Karl Mayer 2014-03-05 16:02:12 UTC

I just run into this:

After removing an old harddrive the system hangs while booting and no chance to get a rescue prompt. There where no hints about a failure too. Everything looks "[ok]" but the system hangs. The only thing i could do is to press "CTRL+ALT+DEL".

Maybe kernelparameter "emergency" would helps me, but without a running system i could not get informations about that.

After reinstalling the old harddrive, the system boots fine. I found that /etc/fstab contains an entry which points to a swap-partition on the old harddrive. After correcting this entry, everything works fine.

I don't know if Oleksii Shevchuk solution would work in my case too, but a failed mount which is caused by /etc/fstab should not result in a unusable system.

My hole story could be found here: https://bbs.archlinux.org/viewtopic.php?id=177951

Comment 4 Lennart Poettering 2014-10-24 00:37:11 UTC

system.conf now knows an overall boot timeout StartTimeoutSec=, plus a configurable action what to do if the timeout is hit. I figure this more or less does what the this bug was about? Closing hence.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.