[Fix] Wait for cloud-init and apt#1208
Conversation
📝 WalkthroughWalkthroughInstallation now marks the system as preparing, waits for cloud-init and package-manager locks through SSH, and then continues server provisioning. ChangesServer boot readiness
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant InstallServer
participant OS
participant RemoteSystem
InstallServer->>InstallServer: Set progress to preparing-system
InstallServer->>OS: Call waitForBoot()
OS->>RemoteSystem: Execute wait-for-boot
RemoteSystem->>RemoteSystem: Wait for cloud-init and package locks
RemoteSystem-->>OS: Complete readiness checks
OS-->>InstallServer: Return
InstallServer->>InstallServer: Continue installation
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@resources/views/ssh/os/wait-for-boot.blade.php`:
- Around line 3-5: Update the wait-for-boot readiness flow around cloud-init and
the lock check to fail closed: bound the cloud-init wait, remove suppressed
failures, treat missing or failing fuser checks as errors, and exit non-zero
when readiness cannot be confirmed or the timeout expires. Ensure all
provider/service command errors propagate through SSH::exec() instead of
allowing provisioning to continue.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: a97fd5fb-ec65-443c-b69b-e53baef80399
📒 Files selected for processing (3)
app/Actions/Server/InstallServer.phpapp/SSH/OS/OS.phpresources/views/ssh/os/wait-for-boot.blade.php
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@resources/views/ssh/os/wait-for-boot.blade.php`:
- Around line 4-8: Update the cloud-init wait command in the boot script so its
exit status is captured through an if/else or || control-flow branch that
remains reachable under set -e. Preserve the timeout-specific message and exit 1
for status 124, while explicitly propagating or normalizing all other nonzero
cloud-init failures.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: ed24046e-7f5e-4759-a086-a5c863591f72
📒 Files selected for processing (1)
resources/views/ssh/os/wait-for-boot.blade.php
|
@RichardAnderson do we need to apply this to all servers |
At the moment its only effecting DO servers (confirmed even the larger servers have this, but it's a worthwhile check regardless, and could solve problems should other providers introduce default cloud-init scripts that run apt updates/upgrades automatically. |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
resources/views/ssh/os/wait-for-boot.blade.php (1)
4-12: 🩺 Stability & Availability | 🟠 MajorKeep boot readiness fail-closed.
The script can still print “System is ready” after readiness checks fail:
- Line 4’s pipeline reports
awk’s success, so a failedcloud-init statuscan be treated as an empty state.- Line 7 ignores every non-zero exit except
124, including cloud-init failures and a missingtimeoutbinary.- The
fuserloop treats command errors as “unlocked”, while lines 26–28 merely log whenfuseris unavailable.Reject unknown/error cloud-init states, every failed wait/probe, missing
fuser, andfuserexecution errors; otherwise provisioning may begin while cloud-init or apt still holds a lock.As per coding guidelines, provider/service errors must bubble up rather than being silently suppressed.
Also applies to: 18-28
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@resources/views/ssh/os/wait-for-boot.blade.php` around lines 4 - 12, Update the wait-for-boot readiness checks to fail closed: preserve the cloud-init probe’s command failure status instead of treating an empty state as ready, reject unknown or failed cloud-init states, and make every non-zero timeout/wait result—including missing timeout—exit with failure. In the fuser lock-check loop, treat missing fuser and any fuser execution error as fatal rather than unlocked, while retaining successful lock detection and waiting behavior.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@resources/views/ssh/os/wait-for-boot.blade.php`:
- Around line 4-12: Update the wait-for-boot readiness checks to fail closed:
preserve the cloud-init probe’s command failure status instead of treating an
empty state as ready, reject unknown or failed cloud-init states, and make every
non-zero timeout/wait result—including missing timeout—exit with failure. In the
fuser lock-check loop, treat missing fuser and any fuser execution error as
fatal rather than unlocked, while retaining successful lock detection and
waiting behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 0dbf6a86-0f63-4c01-b00a-1792ef278e64
📒 Files selected for processing (1)
resources/views/ssh/os/wait-for-boot.blade.php
2 participants
Wait for cloud-init and apt locks to clear before provisioning starts, so new servers (notably DigitalOcean) no longer fail with "Could not get lock /var/cache/apt/archives/lock".
Closes #1205
New command executed at the start:
Server continues past the upgrade process:
DO 1CPU/1GB RAM VPS provisions successfully (where it previously failed):
Summary by CodeRabbit
cloud-initwhen it’s in the running state, andfuser).