Bug 635393
| Summary: | Timeout too short to let kdump.service finish starting | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tomasz Torcz <tomek> |
| Component: | systemd | Assignee: | Lennart Poettering <lpoetter> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | jcm, lpoetter, metherid, mschmidt, nhorman, notting, plautrba |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-10-08 00:53:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Tomasz Torcz
2010-09-19 11:55:44 UTC
Hmm, what would be a suitable timeout here? [CC: Neil Horman] (In reply to comment #1) > Hmm, what would be a suitable timeout here? # SYSTEMCTL_SKIP_REDIRECT=1 time /etc/init.d/kdump start No kdump initial ramdisk found. [OSTRZEŻENIE] Rebuilding /boot/initrd-2.6.36-0.24.rc5.git0.fc15.x86_64kdump.img Starting kdump: [ OK ] 23.23user 59.01system 1:19.45elapsed 103%CPU (0avgtext+0avgdata 106816maxresident)k So in my case it's 1 minute 20 second to generate initrd image. This number is highly machine dependent, and my computer is rather slow by today standards (1.8 GHz Core 2). I've looked into converting /etc/init.d/kdump into systemd job, but the initscript is not simple at all :( Is there a reason this initramfs generation couldn't be done as a %posttrans on packages with the kernel, much like the standard system initramfs is? I have now changed the default timeout for sysv services to 3min (the default for native services stays at 1min, but since it is easy to change the timeout for them this should not be a problem). This is more than twice the amount of time the kdump script required on your machine, and hence I hope we are safe for a while. Or in other words: Should this turn out to still be a too short timeout I'd be willing to bump it to 5mins or even higher. But let's wait until that happens... I suggest a 5 minute timeout by default, since it can be configured down if needed. Otherwise we'll have similar problems - there never used to be any timeout for starting init scripts AFAIK. Jon, how long did the script take on your machine? *** Bug 641227 has been marked as a duplicate of this bug. *** Well, my concern is not one script :) My concern is that the halting problem isn't solvable in general and UNIX systems don't historically put a cap on initscripts (that I'm generally aware of). Therefore, I see the point in having a timeout for sanity (kill a script that just never ends sounds nice), but I think it should default to being much larger than we're likely to see. Those who really care can reduce it down to whatever they like. And hey, thanks for the fast turn around and responsiveness. Appreciated. Have a good weekend. I think discussing whether the timeout should be 3 or 5 mins is a bit of bikeshedding. I'll just follow this algorithm here: double the longest service startup time we are aware of and round it up to the next round value. Which is what I did to come to the 3mins. I think there's little point in further discussions on this. |