FS#33122 - [systemd] Timeout with systemd on boot breaks booting

Attached to Project: Arch Linux
Opened by Nico Schottelius (telmich) - Tuesday, 18 December 2012, 07:13 GMT
Last edited by Dave Reisner (falconindy) - Monday, 24 December 2012, 22:33 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version 4.0.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Summary and Info:

When trying to mount an uncleanly unmounted xfs filesystem that resides on dm-crypt that resides on a raid5,
systemd gets a timeout and considers to drop into the system recovery shell.


Steps to Reproduce:

Create a 6 TiB xfs volume, do an unclean shutdown, reboot.
As xfs does the recovery on mounting, this process can take a long time [tm].

I think the fundamental bug here is that the init system ASSUMES that it
makes sense to add a timeout for a mount (of a local disk!).
This task depends upon

Closed by  Dave Reisner (falconindy)
Monday, 24 December 2012, 22:33 GMT
Reason for closing:  Upstream
Additional comments about closing:  Nothing for Arch do here -- working as upstream intends.
Comment by Nico Schottelius (telmich) - Tuesday, 18 December 2012, 07:28 GMT
Actually, the same happens with a 2 TiB jfs volume as well.
Comment by Nico Schottelius (telmich) - Tuesday, 18 December 2012, 07:55 GMT
And it also seems to happen on clean umounts
Comment by Dave Reisner (falconindy) - Tuesday, 18 December 2012, 11:08 GMT
The default timeout is 90s. I think it's perfectly reasonable to consider a mount job to be dead after this time. If you disagree, feel free to adjust it with fstab options. x-systemd.timeout=0 will effectively disable the timeout.
Comment by Nico Schottelius (telmich) - Tuesday, 18 December 2012, 11:27 GMT
Dave, thanks to the pointer of the fstab option.

It worries me though that existing setups new to change for a change in the init system that introduces unreliability.

I know that arch is currently mainly focussing on desktops, where brokeness is the default behaviour and thus this behaviour may be "expected".

But adding a timeout by default for mounts will make archlinux more unsuitable for servers - one of the motivations why I opened this bug to point out this issue.
Comment by Dave Reisner (falconindy) - Tuesday, 18 December 2012, 11:47 GMT
I tend to think it's sane behavior that we timeout on mount jobs that appear broken. We have rarely (if ever) made explicit accommodations for Arch running on servers. If you'd like to make a case for removing the job timeout for mount units then you'll need to take it upstream. This isn't strictly an Arch concern as we aren't enforcing anything additional.
Comment by Nico Schottelius (telmich) - Tuesday, 18 December 2012, 15:37 GMT
Good point - raising this upstream is definitely a good idea
Comment by Nico Schottelius (telmich) - Wednesday, 19 December 2012, 21:08 GMT
It seems that neither x-systemd.timeout=0 nor x-systemd.device-timeout=0 in /etc/fstab change the behaviour.
I still get the same timeout message (and I also wonder why it times out at all at very boot).
Comment by Dave Reisner (falconindy) - Wednesday, 19 December 2012, 21:16 GMT
Sorry, systemd.mount(5) documents the option as x-systemd.device-timeout.

Loading...