Fix Linux uninstall script failing with a relative path

[jakestenger]

systemd-run runs the detached child as a transient unit with
WorkingDirectory=/, so a relative $0 (e.g. ./uninstall-fleetd-linux.sh
per the uninstall guide) couldn't be found and the removal silently
never ran. Resolve $0 to an absolute path before re-exec.

Fixes #49411

Summary by CodeRabbit

• Bug Fixes
  • Improved the Linux uninstall process so the detached cleanup task always runs from the correct script location.
  • Enhanced compatibility between systemd-based environments and non-systemd systems.
  • Better supports script paths that include spaces or special characters.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 5b09aaef-efa4-446c-a298-224fd7daaa2c

📥 Commits

Reviewing files that changed from the base of the PR and between d35f817 and 2bbfc0f.

📒 Files selected for processing (1)

• it-and-security/lib/linux/scripts/uninstall-fleetd-linux.sh

🚧 Files skipped from review as they are similar to previous changes (1)

• it-and-security/lib/linux/scripts/uninstall-fleetd-linux.sh

---

Walkthrough

The Linux uninstall script now resolves its absolute path before spawning the detached child process. Both the systemd-run branch and the non-systemd background fallback use the resolved path, with quoting added around the embedded path in the fallback command.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main fix: resolving the Linux uninstall script's relative-path failure.
Description check	✅ Passed	The description covers the bug cause, the fix, and the linked issue, though most checklist sections are left blank.
Linked Issues check	✅ Passed	The change resolves the reported relative-path re-exec failure by using an absolute script path for both detached execution paths.
Out of Scope Changes check	✅ Passed	The patch is narrowly scoped to the uninstall script path-resolution fix with no unrelated changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 49411-fix-linux-uninstall-relative-path

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

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 `@it-and-security/lib/linux/scripts/uninstall-fleetd-linux.sh`:
- Line 55: Update the non-systemd background uninstall command around
SCRIPT_PATH to invoke the resolved script directly with its remove argument,
rather than interpolating it into bash -c. Preserve the existing output
redirection, stdin handling, background execution, and root-privileged behavior
while avoiding a second shell parse of SCRIPT_PATH.

🪄 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: CHILL

Plan: Pro

Run ID: 79d5826a-e72c-4607-83ff-d7814e960fcd

📥 Commits

Reviewing files that changed from the base of the PR and between d91d8d7 and d35f817.

📒 Files selected for processing (1)

• it-and-security/lib/linux/scripts/uninstall-fleetd-linux.sh

[spalmesano0]

@jakestenger Did you test if it still works when deployed from Fleet with this update?

[jakestenger]

@jakestenger Did you test if it still works when deployed from Fleet with this update?

@spalmesano0 Yes