master-vodawagner
commented
10 months ago Looking at the timing, its very close to when I powered on the Mac..............wonder if the LaunchDaemon triggered before the Desktop had loaded
Closed master-vodawagner closed 3 weeks ago
master-vodawagner
commented
10 months ago Looking at the timing, its very close to when I powered on the Mac..............wonder if the LaunchDaemon triggered before the Desktop had loaded
blakeusblade
commented
10 months ago We have the same issue...
master-vodawagner
commented
9 months ago I'm going to test if this would be a suitable workaround until @Macjutsu looks into this longer term, fortuantely for my org we don't have a situation where Macs are in a non logged in state.....
# Make sure we have a "normal" logged in user.
dockStatus=$(pgrep -x Dock)
if [[ -z "${current_user_account_name_response}" ]] && [[ "$dockStatus" == "" ]]; then
Macjutsu
commented
9 months ago Indeed the problem is that the new super LD is so fast that it starts up before the user has a chance to log back in... this will take some logic changes to accommodate correctly.
For example, should super wait for a login... but what about computers (like lab/servers) that may sit a the login window for a very long time... not a straight forward fix here.
master-vodawagner
commented
9 months ago Hmm 🤔 would another argument be to have an option to configure for lab computers and set that via config profile?
least that way you could scope logic accordingly
Macjutsu
commented
9 months ago Resolving this issue is enough of a super workflow change that it will require at least one new feature/option.
As such it will be resolved in the next minor point update.
icebook2
commented
7 months ago Just fyi, had this happen on an M1 Pro running Sonoma using super 4.0.3. Updating from OS 14.3 to 14.3.1 the machine just restarted with no dialog. Checked the log and it showed no gui user currently logged in, but I was. It does appear the update workflow had started before I logged in. Then did not recognize an account was active after preparing the update. Other than this it's been working great.
master-vodawagner
commented
7 months ago Still not working as expected just wondered @Macjutsu whether another logic check of "Is the user logged in" could be added at this point of super perhaps?
Thu Feb 15 08:53:54 super[332]: softwareupdate: macOS Sonoma 14.4 Beta 3 download complete, now preparing... Thu Feb 15 09:21:34 super[332]: softwareupdate: macOS update/upgrade is prepared and ready for restart!
master-vodawagner
commented
7 months ago Possibly something like the below on LN5791
current_user_account_name_response=$(scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ {$1=$2="";print $0;}' | xargs)
if [[ -z "${current_user_account_name_response}" ]]; then
current_user_account_name=FALSE
log_super "Final logged in user check, no GUI user found"
else
current_user_account_name=TRUE
log_super "Final logged in user check, GUI user ${current_user_account_name_response} found"
fiPlease try the latest release of super as it may resolve this issue: https://github.com/Macjutsu/super/releases/tag/v4.1.0-beta1
master-vodawagner
commented
4 months ago Please try the latest release of
superas it may resolve this issue: https://github.com/Macjutsu/super/releases/tag/v4.1.0-beta1
Will be the first thing I try when I’m back at work in June
Macjutsu
commented
2 months ago There are many updates in https://github.com/Macjutsu/super/releases/tag/v5.0.0-beta2 that may resolve this behavior. Please try it out.
Macjutsu
commented
3 weeks ago There have been so many changes to the latest version of super that I'm closing this issue.
https://github.com/Macjutsu/super/releases/tag/v5.0.0-beta3
If you find it persists with the latest builds of super please open a new issue.
I think the logic that checks for a logged in user isn't working accurately, I was most definitely logged in when this kicked off the MDM update and triggered the restart with no visual cues. Luckily I didn't have any vital stuff going on when it rebooted :P