Skip to main content
Question

How to know when a Mac is at the login window

  • July 26, 2021
  • 8 replies
  • 23 views
I
Forum|alt.badge.img+7

I'm working on getting our Intel Macs upgraded to Big Sur. When doing that, I'm finding that a couple of applications are still prompting for kernel extension or system extension approval despite having it. But, if I let the upgrade process get to the login window, restart it there, then log in those prompts go away. So to fix that, I'm trying to automate a reboot when at the login window. That process, using a self-destructing script and LaunchDaemon, works in general but I have yet to identify the right process that runs the login window. Basically, I seem to be hitting the reboot too early. I have tried against the following:
loginwindow
SecurityAgent
logind


tl;dr What process is running that makes this screen come up and stay up(but for Big Sur, not that it will likely matter)?

 

    8 replies

    perryd84
    Forum|alt.badge.img+10
    • perryd84
    • Contributor
    • July 27, 2021

    I use "pgrep loginwindow" in my Jamf connect script and that works perfectly.

    My DEP devices enrol and once the device gets to the login screen a script runs to find the login window process. If it's running it terminates it and runs the Jamf connect login screen instead.

    This is the part I use to kill the login window.

    if pgrep loginwindow; then killall -HUP loginwindow fi

    You could change "killall -HUP loginwindow" to do a reboot. Maybe add in a sleep delay so that whatever you need to run runs and does whats needed and then reboots after 1min or something?

    mm2270
    Forum|alt.badge.img+24
    • mm2270
    • Legendary Contributor
    • July 27, 2021

    loginwindow would be the process as @perryd84 mentioned, but the problem is the loginwindow is technically always running. You can test this by entering

     

    ps axc | grep loginwindow

     

    in Terminal and you'll see it returns a result.

    The better thing to do here, assuming your LaunchDaemon is running a script, is to look at this in the reverse way. Instead of checking for the existence of the login window, look for something like the Dock or Finder process running (maybe even both), which will only be running once you're past that login window and into the account. If those aren't running, either the machine is in a bad state of affairs or it's sitting at the login window. 😊

    From there you can have your script perform the reboot. Just be certain it's destroying itself as you stated or you'll have a perpetually rebooting Mac!

    Edit: Ok, so I happened to re-read your original post and I can see now that even my proposed solution isn't going to work, because if it's a LaunchDaemon it will get called even before the Mac gets to the actual login window. I didn't read carefully enough before. You mentioned the reboot was happening too soon, and I think the same thing will happen if you have the script look for the Dock or Finder.

    What might work is to have the script wait (read: loop) for a condition where the loginwindow is running, but the Finder and/or Dock are not. That might do the trick. When the Mac is booting up, the loginwindow process shouldn't be active until it actually loads and you see it on screen. So if the script finds the loginwindow = running and Dock = not running, that should be the right time to trigger the restart.

    AJPinto
    Forum|alt.badge.img+26
    • AJPinto
    • Legendary Contributor
    • July 28, 2021

    Sounds like you may not have something configured correctly. We had a lot of issue with KEXTs and System Extensions when we started testing macOS Big Sur beginning of the year. Most of it was just stuff not configured correctly.

     

    What applications are giving you grief? 

    I
    Forum|alt.badge.img+7
    • imy
    • Author
    • Contributor
    • July 28, 2021

    loginwindow would be the process as @perryd84 mentioned, but the problem is the loginwindow is technically always running. You can test this by entering

     

    ps axc | grep loginwindow

     

    in Terminal and you'll see it returns a result.

    The better thing to do here, assuming your LaunchDaemon is running a script, is to look at this in the reverse way. Instead of checking for the existence of the login window, look for something like the Dock or Finder process running (maybe even both), which will only be running once you're past that login window and into the account. If those aren't running, either the machine is in a bad state of affairs or it's sitting at the login window. 😊

    From there you can have your script perform the reboot. Just be certain it's destroying itself as you stated or you'll have a perpetually rebooting Mac!

    Edit: Ok, so I happened to re-read your original post and I can see now that even my proposed solution isn't going to work, because if it's a LaunchDaemon it will get called even before the Mac gets to the actual login window. I didn't read carefully enough before. You mentioned the reboot was happening too soon, and I think the same thing will happen if you have the script look for the Dock or Finder.

    What might work is to have the script wait (read: loop) for a condition where the loginwindow is running, but the Finder and/or Dock are not. That might do the trick. When the Mac is booting up, the loginwindow process shouldn't be active until it actually loads and you see it on screen. So if the script finds the loginwindow = running and Dock = not running, that should be the right time to trigger the restart.


    The issue with my use case is that this won't work. The process is as follows:
    User clicks on the upgrade button in self-service
    Upgrade starts, reboots as part of the upgrade, shows a progress bar, completes
    The user is now at the login screen
    <I want to reboot here>

    The issue is that Finder, Dock, et cetera aren't running during that upgrade process, so if I look for the absence of these then I reboot way too early, which is my current issue.

    I
    Forum|alt.badge.img+7
    • imy
    • Author
    • Contributor
    • July 28, 2021

    Cisco AMP, Cisco AnyConnect, and Google Drive.

    The first two seem to be due to switching from a kernel extension to a system extension; apparently, neither product worked properly with system extensions in Catalina, so Cisco advised using kernel extensions instead. The system extensions now work. I'm switching the config profiles for these out right before the upgrade starts.

    Drive still uses kernel extensions. I'm getting around this by ensuring the Mac is running the latest version of Drive and the user is logged onto it before starting the upgrade. This results in the prompt, but it is approved.

    Note that all of these work after a reboot, and it doesn't matter if I acutally log in or not before the reboot. So long as the reboot happens sometime after the login window is shown it always works. This is what makes me think all is working, but takes one more reboot to get it to the right state.

    I
    Forum|alt.badge.img+7
    • imy
    • Author
    • Contributor
    • July 28, 2021

    I got this to work.

    The script I'm using, with a few modifications, is this one - https://github.com/kc9wwh/macOSUpgrade/blob/master/macOSUpgrade.sh

    I remembered that script took some action when the upgrade was done, so I found this:

    ## Wait until the upgrade process completes INSTALLER_PROGRESS_PROCESS=\\$(pgrep -l "Installer Progress") until [ "\\$INSTALLER_PROGRESS_PROCESS" = "" ]; do echo "\\$(date "+%a %h %d %H:%M:%S"): Waiting for Installer Progress to complete." >> /usr/local/jamfps/firstbootupgrade.log /bin/sleep 60 INSTALLER_PROGRESS_PROCESS=\\$(pgrep -l "Installer Progress") done

    Now that didn't work as-is for unknown reasons (it never showed the Installer Progress process as running) so I changed it to this:

    INSTALLER_PROGRESS_PROCESS=$(ps -A | grep "Installer Progress" | grep -v "grep") until [ "$INSTALLER_PROGRESS_PROCESS" = "" ]; do echo "$(date) Waiting for Installer Progress to complete." >> $logLoc /bin/sleep 60 INSTALLER_PROGRESS_PROCESS=$(ps -A | grep "Installer Progress" | grep -v "grep") done # other cleanup stuff shutdown -r now

    This works great. I'm going to trim down that minute wait to something much shorter though, and I want to see if I can automate an authenticated reboot rather than a standard one. Thanks for everyone's help, as you got me thinking about this in the right direction.

    AJPinto
    AJPinto
    Forum|alt.badge.img+26
    • AJPinto
    • Legendary Contributor
    • July 28, 2021

    Bah, AnyConnect. AnyConnect is a nightmare and JAMF still does not fully support network extensions which AnyConnect needs. Also, if a Network Extension installs BEFORE the configuration profile that Manages the Network Extension there is no way to approve it with MDM, they user must click the buttons which is the reboot stuff you are seeing. This is basically working as intended… Thank you, Apple...

    I would say try to try to flip devices from KEXTs to SEXTs (SystemEXTensions you can never unsee it now) a few days before trying to upgrade. Even if you let the KEXT and SEXT run side by side. Let the device marinate a bit. I think doing this KEXT to SEXT change and the OS upgrade at the same time may be compounding problems. Cisco's Network extensions were a nightmare for us and still are not perfect.

    What version of AnyConnect are you using? JAMF gave us this guide back in Jan or so, this is when I learned if the Network Extension is installed 1st it must be manually approved.

    Google will likely be a problem until you can move over to System Extensions. Big Sur still supports KEXTs but its more of a legacy thing and they dont work very well. I'm glad the rebooting it working. It also just clicked that was a screenshot of Mojave, we upgraded from Catalina to Big Sur I try to avoid skipping OS versions for many reason.

    Apparently JAMF does not like attachments, so here are screenshots lol. 

     

     

    G
    Forum|alt.badge.img+10
    • gabester
    • Valued Contributor
    • July 29, 2021

    Bah, AnyConnect. AnyConnect is a nightmare and JAMF still does not fully support network extensions which AnyConnect needs. Also, if a Network Extension installs BEFORE the configuration profile that Manages the Network Extension there is no way to approve it with MDM, they user must click the buttons which is the reboot stuff you are seeing. This is basically working as intended… Thank you, Apple...

    I would say try to try to flip devices from KEXTs to SEXTs (SystemEXTensions you can never unsee it now) a few days before trying to upgrade. Even if you let the KEXT and SEXT run side by side. Let the device marinate a bit. I think doing this KEXT to SEXT change and the OS upgrade at the same time may be compounding problems. Cisco's Network extensions were a nightmare for us and still are not perfect.

    What version of AnyConnect are you using? JAMF gave us this guide back in Jan or so, this is when I learned if the Network Extension is installed 1st it must be manually approved.

    Google will likely be a problem until you can move over to System Extensions. Big Sur still supports KEXTs but its more of a legacy thing and they dont work very well. I'm glad the rebooting it working. It also just clicked that was a screenshot of Mojave, we upgraded from Catalina to Big Sur I try to avoid skipping OS versions for many reason.

    Apparently JAMF does not like attachments, so here are screenshots lol. 

     

     


    This is pretty old school unix but the finger command should return no results other than its default line, so if you did something like finger | grep -v "Time   Office" you should get a null result if no one is logged in. 

     

    ... meant to reply to the parent not to your AnyConnect rant... grumble grumble redesign. 

     

    Additional update - just ran a policy with the finger command, the result was: 

    No one logged on.

    Terms & ConditionsCookie settingsAccessibility statement