Ensure MacOS desktop app launched as correct user#27296
Conversation
| if len(match) > 1 && match[1] != "" && match[1] != "_mbsetupuser" { | ||
| return &match[1], nil | ||
| } |
There was a problem hiding this comment.
since root is not a GUI user, we don't have to filter for that here.
sgress454
changed the title
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #27296 +/- ##
==========================================
- Coverage 63.89% 63.88% -0.02%
==========================================
Files 1731 1731
Lines 164611 164896 +285
Branches 4507 4507
==========================================
+ Hits 105176 105339 +163
- Misses 51267 51360 +93
- Partials 8168 8197 +29
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
getvictor
left a comment
getvictor
left a comment
There was a problem hiding this comment.
The code looks good.
We've seen the issue with Fleet Desktop launching for users who have installed Fleet for the first time, like prospects trying out Fleet. So, I don't understand how this change would fix that use case.
For QA, please test on a Mac with 2 users -- 1 logs out and another one logs in, and Fleet Desktop should work for both.
There are anecdotal reports of
Will do! |
lucasmrod
left a comment
lucasmrod
left a comment
There was a problem hiding this comment.
LGTM!
Great finding!
- Left a comment/question.
- Pending
orbit/changes/.
|
Updated code from PR review and added changelog 👍 |
sgress454
deleted the
sgress454/25924-ensure-correct-user-before-launching-desktop
branch
|
@sgress454 @getvictor I reproduced this issue after updating to the latest macOS (15.3.2) And then I pushed |
3 participants
For #25924
This PR attempts to fix the issue where the Fleet desktop icon sometimes fails to appear on MacOS hosts until the hosts are rebooted. Anecdotal evidence points to this being an issue when system setup is happening, leading to the theory that Orbit is attempting to launch the app as
_mbsetupuserrather than the real logged-in user. The fix here is to use a different command to get the name of the logged-in user (ignoring_mbsetupuserif it appears), and to launch the desktop app as that user usingsudo.I have tested this on MacOS and Ubuntu hosts, and verified that the desktop app launches as expected on both.
We don't have a solid reproduction scenario for the issue, but we do have some ways to look for relevant errors, so we can try this out and see if those errors cease.