scheduler: avoid waiting for stdout eof of /etc/network/ scripts #274
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Scripts in /etc/network/ are executed using `exec_command` which captures stdout by default, and thus waits for stdout end-of-file via `Popen.communicate()`. However, this can cause hangs if the network script executes a long-running command in the background. Can be reproduced by putting the following (executable) script in /etc/network/if-up.d/: #!/bin/sh sleep 5& This script will cause `ifreload -a` to wait for 5 seconds per network interface. To avoid waiting, do not capture stdout when executing /etc/network/ scripts. This also improves compatibility with ifupdown, which runs the above script in the background. Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
|
Hi, any thoughts on this patch? I first started looking into this because some Proxmox VE users reported hanging boots if both |
|
Hi All, what should we be doing to get this solved? I lost few hours tshooting this so now I am srronger :) and thanks @frwbr for reporting the issue. |
|
Thanks for the merge! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi,
As mentioned in the commit message, this patch is intended to increase compatibility with ifupdown with regards to how
/etc/network/scripts are run (see commit message for a simple example).It also fixes an issue where a Debian 12 host hangs indefinitely on boot if current
ifupdown2master as well as the packagesntpsecandntpsec-ntpdateare installed.The hang happens because
ntpsec-ntpdateinstalls a script/etc/network/if-up.d/ntpsec-ntpdate-- the following excerpt is relevant:The
invoke-rc.dcall amounts tosystemctl start ntpsec, so the script essentially runssystemctl start ntpsecin a background subshell. Unfortunately this command blocks indefinitely (see below). Since ifupdown2 waits for stdout end-of-file, it waits for the command to terminate even though it is run in a background subshell. As a result, the boot process hangs indefinitely. I presume thesystemctl start ntpseccommand blocks indefinitely because ntpsec.service setsWants=network.target, butnetwork.targetwill only become available whenifupdown2finishes, which it never does. Withifupdowninstead ofifupdown2, the boot does not hang as the blocking command is executed in the background.I guess the hang issue can also be fixed by patching the unit file of
ntpsecand/or the network script ofntpsec-ntpdate-- to be honest I have not dug deep enough yet to fully grasp the network script. As this PR also increases compatibility with ifupdown, I decided to send it here anyway. Let me know what you think.Thanks and best wishes,
Friedrich