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.

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

Add additional guards for nix process detach #210

Merged
merged 1 commit into from
Jun 11, 2019

Conversation

reidmv
Copy link
Contributor

@reidmv reidmv commented Jun 5, 2019

Observing some weird race-condition-y behaviors where the nix.sh script
previously was not reliable in rebooting systems. Most of the time with
an attached TTY, the subprocess was still being killed when the
TTY-attached parent shell terminated.

Adding a sync call seems to work around the problem.

Adding an explicit disown for linux just for completeness. It was not
shown to help with the observed race condition, which is resoseems to
work around the problem.

Adding an explicit disown for linux just for completeness. It was not
shown to help with the observed race condition (which is resolved by
sync). disown is a bash built-in, and this is a bash script so we
should be fine to use it.

Observing some weird race-condition-y behaviors where the nix.sh script
previously was not reliable in rebooting systems. Most of the time with
an attached TTY, the subprocess was still being killed when the
TTY-attached parent shell terminated.

Adding a `sync` call seems to work around the problem.

Adding an explicit `disown` for linux just for completeness. It was not
shown to help with the observed race condition (which is resolved by
`sync`). `disown` is a bash built-in, and this is a bash script so we
should be fine to use it.
@@ -30,7 +30,12 @@ else
timeout_min=$(($timeout/60))
timeout_sec=$(($timeout%60))
nohup bash -c "sleep $timeout_sec; shutdown -r +$timeout_min $message" </dev/null >/dev/null 2>&1 &
disown
Copy link
Contributor

@MikaelSmith MikaelSmith Jun 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what scenario would make this necessary, but based on https://unix.stackexchange.com/a/148698 I don't believe it hurts.

# There are some weird race conditions that might make detached jobs still die
# when this shell exits. The sync (which otherwise shouldn't do much) seems to
# eliminate them.
sync
Copy link
Contributor

@MikaelSmith MikaelSmith Jun 10, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😕 🤷‍♂

@MikaelSmith
Copy link
Contributor

Was it particular Linux variants that had this problem?

@reidmv
Copy link
Contributor Author

reidmv commented Jun 10, 2019

I saw the issues on a CentOS 7 VM, on Platform9. Definite race condition-y, sometimes it worked, sometimes it didn't. Worked 100% of the time with the sync. 🤷‍♂

@pmcmaw pmcmaw merged commit 1d84241 into puppetlabs:master Jun 11, 2019
@pmcmaw
Copy link
Contributor

pmcmaw commented Jun 11, 2019

Thank you for your PR @reidmv :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants