Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Root FS device times out after 90 seconds #6402

Closed
Werkov opened this issue Jul 18, 2017 · 9 comments
Closed

Root FS device times out after 90 seconds #6402

Werkov opened this issue Jul 18, 2017 · 9 comments
Assignees
@poettering
Labels
fstab-generator
Milestone
v235

Comments

@Werkov
Copy link
Contributor

Werkov commented Jul 18, 2017 •
edited

Submission type

  • Bug report

systemd version the issue has been seen with

v234 (after d9732d7), actually seen on v228 with backport of that commit

Used distribution

SLES 12 SP2

In case of bug report: Expected behaviour you didn't see

systemd waits until the device for root FS appears ready

In case of bug report: Unexpected behaviour you saw

Waiting for root FS device (on LVM) timed out after 90 seconds.

In case of bug report: Steps to reproduce the problem

(Set up a root FS on device that takes long to initialize, after reboot it can be observed.)

dracut uses JobTimeoutSec=0 to disable timeout for root FS device. It still applies but since d9732d7, there is another timeout of JobRunningTimeoutSec= which defaults to 90 seconds.

Some solutions I can think of:

  1. Ensure backwards compatible interpretation of JobTimeoutSec=, in branch job-timeout-running-compat.

  2. Modify dracut so that it uses JobRunningTimeoutSec= for device units (that would leave other users affected by this though).

  3. Keep only JobTimeoutSec= for devices and explicitly specify JobRunningTimeoutSec= for fstab-generator device units, in branch job-timeout-running-explicit (not complete, would use the running timeout only when a timeout is explicitly specified in fstab, which is not desirable).

I'd prefer option 1. What do you think?
@poettering poettering added this to the v235 milestone Jul 20, 2017
@keszybz
Copy link
Member

keszybz commented Sep 26, 2017

See also https://bugzilla.redhat.com/show_bug.cgi?id=1491847.

@poettering poettering self-assigned this Sep 27, 2017
poettering added a commit to poettering/systemd that referenced this issue Sep 27, 2017
@poettering
unit: when JobTimeoutSec= is turned off, implicitly turn off JobRunni…
bfb52ed 
…ngTimeoutSec= too

We added JobRunningTimeoutSec= late, and Dracut configured only
JobTimeoutSec= to turn of root device timeouts before. With this change
we'll propagate a reset of JobTimeoutSec= into JobRunningTimeoutSec=,
but only if the latter wasn't set explicitly.

This should restore compatibility with older systemd versions.

Fixes: systemd#6402
@poettering poettering mentioned this issue Sep 27, 2017
Merged
@poettering
Copy link
Member

My proposal to fix this is waiting in #6931. @Werkov any chance you can give this a whirl if it fixes the issue for you?

That said, I am pretty sure dracut should be fixed too, and set both JobRunningTimeoutSec= and JobTimeoutSec= to infinity (instead of just one, and instead of 0)

@poettering poettering mentioned this issue Sep 27, 2017
Closed
@poettering
Copy link
Member

I filed a dracut bug now in dracutdevs/dracut#289 so that their side is updated too

poettering added a commit to poettering/systemd that referenced this issue Sep 28, 2017
@poettering
unit: when JobTimeoutSec= is turned off, implicitly turn off JobRunni…
11137be 
…ngTimeoutSec= too

We added JobRunningTimeoutSec= late, and Dracut configured only
JobTimeoutSec= to turn of root device timeouts before. With this change
we'll propagate a reset of JobTimeoutSec= into JobRunningTimeoutSec=,
but only if the latter wasn't set explicitly.

This should restore compatibility with older systemd versions.

Fixes: systemd#6402
@Werkov
Copy link
Contributor Author

Werkov commented Oct 2, 2017

Thanks, I like this approach of propagating the value only when it wasn't explicitly set (paying with the introduced flag).
I gave the patch a try (based on v234) and it waits infinitely for the root FS device as is dracut's intention.

One remark though -- why to propagate only the 'infinity' value? If the user configures rd.timeout= kernel cmdline in (90, +∞), they are still undercut with the 90 seconds JobRunningTimeoutSec=.

@keszybz keszybz closed this as completed in eae51da Oct 5, 2017
@fbuihuu
Copy link
Contributor

fbuihuu commented Oct 5, 2017

@keszybz I'm not sure why you closed this one without answering @Werkov's question.

AFAICS the question is valid, isn't it ?

@poettering
Copy link
Member

@fbuihuu in case this wasn't clear: i reworked my patch before @keszybz merged it, doing what @Werkov suggested. hence all should be good.

@fbuihuu
Copy link
Contributor

fbuihuu commented Oct 6, 2017

ah ok I missed that. So everything is fine, thanks.

@fbuihuu
Copy link
Contributor

fbuihuu commented Oct 6, 2017

One minor nit though: I think this behavior could have been documented somewhere.

@keszybz
Copy link
Member

keszybz commented Oct 6, 2017 via email

Werkov pushed a commit to Werkov/systemd that referenced this issue Oct 23, 2017
@poettering @Werkov
unit: when JobTimeoutSec= is turned off, implicitly turn off JobRunni…
7673a8d 
…ngTimeoutSec= too

We added JobRunningTimeoutSec= late, and Dracut configured only
JobTimeoutSec= to turn of root device timeouts before. With this change
we'll propagate a reset of JobTimeoutSec= into JobRunningTimeoutSec=,
but only if the latter wasn't set explicitly.

This should restore compatibility with older systemd versions.

Fixes: systemd#6402

(cherry picked from commit d8fdc62)

[mkoutny: resolved conflicts:
	src/basic/time-util.c
                drop parse_sec_fix_0 as we store infinity as 0
	src/core/load-fragment-gperf.gperf.m4
	        adjust context (remove aliases)
	src/core/load-fragment.c
	        adjust context, use parse_sec
	src/core/load-fragment.h
	        adjust context, use parse_sec
	src/core/unit.h
	        adjust context]
SergioAtSUSE pushed a commit to SergioAtSUSE/systemd_systemd that referenced this issue Jun 7, 2018
@poettering @fbuihuu
unit: when JobTimeoutSec= is turned off, implicitly turn off JobRunni…
1cdd944 
…ngTimeoutSec= too

We added JobRunningTimeoutSec= late, and Dracut configured only
JobTimeoutSec= to turn of root device timeouts before. With this change
we'll propagate a reset of JobTimeoutSec= into JobRunningTimeoutSec=,
but only if the latter wasn't set explicitly.

This should restore compatibility with older systemd versions.

Fixes: systemd#6402
(cherry picked from commit eae51da)

[fbui: adjust context]
[fbui: fixes bsc#1004995]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@poettering poettering

Labels
fstab-generator
Milestone
v235
Development

No branches or pull requests
4 participants
@fbuihuu @keszybz @Werkov @poettering