docs: wait for the dpkg lock before the scripted deb install - #4330
Open
ayushsingh82 wants to merge 1 commit into
Open
ayushsingh82 wants to merge 1 commit into
ayushsingh82 wants to merge 1 commit into
Conversation
client/INSTALL.md directs users to pipe setup.deb.sh to bash. That Cloudsmith template (not ours) runs apt-get install with all output redirected to a throwaway log file. On a freshly-booted Ubuntu LTS host, unattended-upgrades.service holds /var/lib/dpkg/lock-frontend, so apt-get blocks waiting for the lock with DPkg::Lock::Timeout=-1 (wait forever) — and apt's own "Waiting for cache lock..." message is swallowed by the redirect. The user sees nothing and assumes a hang; it usually clears on its own within ~20 min once the background upgrade finishes. Added a preflight one-liner before the curl | bash that waits for the lock and prints why, so the wait is visible instead of silent. Cheapest of the three options in the issue (own setup.deb.sh / Cloudsmith template customization / doc-only mitigation); the durable fix would be shipping our own setup script, tracked separately if wanted. Closes malbeclabs#3540.
Contributor
Author
|
@ben-dz could you take a look when you have a chance? |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Problem
Closes #3540.
The scripted install path documented in
client/INSTALL.mdcan hang indefinitely atRUN: Attempting to install 'apt-transport-https' ...on fresh Ubuntu LTS hosts. Restarting the script clears it up, so the impact is cosmetic — but the user sees zero feedback for several minutes and reasonably concludes the installer is broken.Root cause:
client/INSTALL.mddirects users to pipesetup.deb.sh(a Cloudsmith template, not ours) to bash. That script runsapt-get install -y "$tool" &>$tmp_log, redirecting all output to a throwaway log. On a freshly-booted Ubuntu LTS host,unattended-upgrades.serviceholds/var/lib/dpkg/lock-frontend, soapt-get installblocks waiting for the lock. apt's defaultDPkg::Lock::Timeout=-1means wait forever, and apt's normalWaiting for cache lock: held by process N (unattended-upgr)...message is swallowed by the redirect. It typically unblocks within ~20 min once the background upgrade finishes.Fix
Of the three options in the issue (ship our own
setup.deb.sh, customize/PR the Cloudsmith template, or a doc-only mitigation), this takes the cheapest one with real impact: a preflight one-liner inclient/INSTALL.mdbefore thecurl | bash, waiting for the dpkg lock and printing why, so the wait is visible instead of silent. The durable fix (our own install script with a real timeout and non-swallowed output) is a separate, bigger change — happy to track that separately if wanted.Testing Verification
Docs-only change; verified the added shell snippet's syntax and that it matches the exact one-liner proposed in the issue.