Intermittent login issues on macOS 15.1.1

Stuart_P
New Contributor III

Hi,

We're starting to see a number of cases being raised internally about some of our Macs (all on macOS 15.1.1) having intermittent login issues.  Our devices are bound to AD and our users have been logging on fine for some time but now we're starting to get issues.  Sometimes the logins are fine.  Sometimes they take ~10 mins and sometimes they appear to stall completely (waited over 2.5 hours in testing) even on the same device.  The login screen appears to freeze (the time doesn't change) and you eventually get the spinning beachball.  SSH is still working and you can run a "jamf policy" successfully.  "Screen Sharing" reports that the user who has attempted to log into the device is the active user when you connect.

Can anyone share some tips as to how we would start to investigate this sort of issue let alone resolve it???

Thanks

Stuart

46 REPLIES 46

Stuart_P
New Contributor III

This seems to be the information we're seeing in the system log...

 

sh-3.2# tail -F /var/log/system.log

Dec 11 16:10:37 na-622-cbca4957 loginwindow[325]: Calling completion handler for 0x600001ca5580
Dec 11 16:10:37 na-622-cbca4957 loginwindow[325]: client 0x600001ca5580: phaseName = "loginwindow Boot" is already done
Dec 11 16:10:37 na-622-cbca4957 loginwindow[325]: client 0x600001ca5580: phaseName = "loginwindow Boot", hide progress UI called
Dec 11 16:10:37 na-622-cbca4957 loginwindow[325]: ISAP: hide progress UI called
Dec 11 16:10:37 na-622-cbca4957 loginwindow[325]: client 0x600001ca5580: phaseName = "loginwindow Boot" is being released
Dec 11 16:10:37 na-622-cbca4957 loginwindow[325]: Releasing Connection
Dec 11 16:10:42 na-622-cbca4957 loginwindow[325]: The connection was interrupted, calling interruption handlers
Dec 11 16:11:08 na-622-cbca4957 loginwindow[325]: There is still an active connection
Dec 11 16:12:07 --- last message repeated 1 time ---

Shyamsundar
Valued Contributor

We had some network dropout issues reported on macOS 15+, it got fixed on macOS 15.2. I would sugesst upgrading to macOS 15.2 and try 

Stuart_P
New Contributor III

Most of our affected devices have been updated to 15.2 and this does indeed appear to have resolved the issue.

Stuart_P
New Contributor III

Sorry to come back and report that 15.2 does not appear to have fixed the issue.

Kevm
New Contributor III

Hi @Stuart_P  did you ever resolve this? I have the same issue on Sonoma. A complete erase and install seems to be the only fix I have.

 

Stuart_P
New Contributor III

Hi Kevm, we dug for hours, looking for a root cause, but we couldn't find anything.  We found it was about 15 Mac Minis across about 4 labs (probably ~100 devices) that exhibited the problem so wasn't quite as wide-spread as we initially thought.  We've now rebuilt them all as that was the only solution we found.

As above, we found this in the system log...
loginwindow[325]: The connection was interrupted, calling interruption handlers

... but we never figured out what was causing the interruption (I'm sure a better macOS admin may be able to track it down but we couldn't get anywhere and found the quickest solution was to wipe and rebuild).

Kevm
New Contributor III

Thanks for the update Stuart. I have around 650 Macs but only a handful of reports. They hardly get reported so I didn't know it was happening for a while.Problem is we have so many launch agents, adobe chrome, AV, the list goes on.You dont have Netnotify or Smoothwall installed do you?. As you found it appears just the log in window process is being interrupted. I am currently compiling a list of know bad ones to re install. If I do find a magic easy fix I will report back here.

Stuart_P
New Contributor III

No, we have neither of those two things.  Rebuilding the devices with 0 changes to the deployed content (although I can't talk about what might have historically been on the devices and since removed from Jamf) tells me that it was most likely to be something to do with an update to 15.x having gone slightly wrong somewhere.  The devices rebuilt to macOS 14.x and all had 15.x re-applied without issue.

Kevm
New Contributor III

Yes I think almost definitely an update. Never had this issue until 14.x.

singletary
New Contributor III

Although I don't have any fixes yet, I wanted to chime in and say that we are seeing the same thing across our lab Macs.

My current theory is that this is macOS update-related, since I'm seeing a number of additional HD partitions showing up in Disk Utility once this issue presents, like "Macintosh HD - Data - Data" and "Macintosh HD - Data - Data - Data" that seem to be indicative of in-progress updates failing or getting interrupted somehow before they complete.

Wiping out the drives and reinstalling the latest version of macOS seems to fix the issue, at least until there is another macOS update made available. Some will update successfully, and I'm only seeing this login issue on Macs that are not on the latest dot release update.

I've been trying to figure this out for a couple of months now, but unfortunately haven't found anything particularly useful in the logs. Seems like there's lots of possible threads to spend time following, but since rebuilding is a sure fix we've been mostly just doing this to get them running again.

Are you still seeing this issue with the updates that have come out since you started this thread?

Kevm
New Contributor III

Thanks for the update, it's good to know we are not alone Eh?. I did open a report with my apple developer account. heard nothing as yet. Ticket # FB14664272

These commands have worked on some rare occasions for me after ssh into the affected Mac:

sudo killall HUP loginwindow (this obviously kills the process causing the issue)

Wait a few seconds then:

sudo launchctl start com.apple.loginwindow

Sudo reboot. This does work sometimes. but yes erase and install is the best option.

Are you bound to AD too?

In answer to your question, it's hard to say as I only started making proper notes of the rebuilt ones. I did have one that reverted to the issue again. I have definitely had some affected after 15.3.1 update and 14.7.2.

I will report back here if the apple come up with anything (won't hold my breath) but agin the ID is  FB14664272 if you want to chip in.

 

singletary
New Contributor III

Yes, also AD bound (unfortunately). Appreciate the information on the developer ticket. I'll have a look and see if there's anything I can contribute to it.

It's certainly "nice" to know that I'm not alone here. It's been a really annoying issue to try and track down and there's always some comfort in knowing others are going through the same ridiculous issue with me. ;)

Stuart_P
New Contributor III

Not knowing the Apple ecosystem too well, how would I chip into the bug ID if I wanted to?

Kevm
New Contributor III

Hi Stuart, If you have an appleseed for IT account (good idea as you get updates on security releases etc), you can file a bug report there. Not sure if this is the official way, but you could reference the number I was given in there I guess. Regarding the AD binding, apple don't support that so we may be stuffed. I have managed to get NomAD to do this effectively but it creates an ugly log ion screen and I don't know if this problem we are seeing just pertains to AD bound Macs.

Kevm
New Contributor III

Forgot to say I will check disk utility next time.

singletary
New Contributor III

Interested to hear what you find!

Stuart_P
New Contributor III

Interestingly we have also had this issue re-occur in the last few days and rebuilt most, if not all, of the devices already.

We will try and test those commands and check disk utility too then next time we get the issue and report back.  Our devices are AD-bound.

Kevm
New Contributor III

That's worrying, I have nearly 700 Macs across 2 sites. I am looking at testing Xcreds but that is a paid solution.

Kevm
New Contributor III

Are these ones that have been updated since a rebuild?

 

singletary
New Contributor III

Mine, at least, have had the same issue happen again after a rebuild. Something I'm working on now is forcing updates or manually updating computers instead of allowing macOS to manage the update installation itself.

Since the issue does not seem to recur in any predictable way it is hard to tell if this is working but manual updates have not, so far, triggered this issue. I've only ever notice it happen after a new macOS update is available. Some will have updated automatically with no issue, but the ones that are affected have always had an update available (and the partitions in Disk Utility make me think it tried to update and failed).

Stuart_P
New Contributor III

We need to track down the logs from when it happened the first time to compare (this might be useful information).

We use native AD binding.
We have only seen this issue on Mac Minis.
We use S.U.P.E.R.M.A.N. to update our lab Macs silently overnight.
It was only ~20% of the Mac Mini devices where we saw the issue the first time.  I THINK it's about the same for the second time around.
It definitely feels related to Mac Updates.

singletary
New Contributor III

We're also doing native AD binding.

We've only seen this on our 2019 i7 iMacs. Our 2022 Mac Studios seem unaffected so far, even though they're deployed the exact same way.

Also seems to be around 20-30% of our Macs affected at once.

Kevm
New Contributor III

Ours has been mainly M1 and M2 Mac minis, I have had a few i5 21.5 iMacs affected too. None of our 27" iMacs, so it seems to be Sonoma onwards that is affected which must be an OS update.

Kevm
New Contributor III

My updates are managed through our MDM server using DDM (declarative device management). They still pull the updates from apple. I wonder if there are being interrupted somehow. Unfortunately our network has packet shaping on (fortigate) which I think causes all sorts of issues. That said I haven't had many updates fail until recently. I have just finished a test setup with NoMAD and the Macs log in fine without AD binding. If I can't solve the issue, next problem Mac I have I will install this and see if that fixes it. There are no benefits other than authentication for the AD bind anyway.

 

singletary
New Contributor III

I would love to move away from AD binding, but the vast majority of our Macs are in a lab environment where binding has made the most sense so far. Are you using NoMAD in a lab environment?

Kevm
New Contributor III

I have been testing NoMAD and it works great. The only thing I have seen so far is after a reboot occasionally the login screen is in the corner of the display. It does need a profile though to customise it. The next step up is XCreds bit I doubt our college would fork out for that.

Kevm
New Contributor III

I have been using AD for about 15 years with relatively few issues. I can't have this happening for another 6 months though. I plan to erase and install the whole estate during the summer, But if NoMAd solves the problem on the current issue I might just stick with that.

singletary
New Contributor III

Same. It's been mostly non-problematic for us for a very long time, which is why I'm thinking this has to do with the updates instead of AD. Not sure why this is only impacting a small number of computers. We're also unable to reproduce this manually, by running updates ourselves on the machines. This only seems to happen when macOS updates automatically.

We're configured to defer major software updates for 90 days, but otherwise let macOS manage the updates itself.

Kevm
New Contributor III

Hello all, Made a discovery today that 'may' have a bearing on the issues. I managed to get into three Macs today that were stuck at logi n with a local account. All 3 the students had tried to join them to the wifi (disabled by me) so wondering whether that was affecting the ethernet connection? Something else to think about. One now works after forgetting that SSID, another that was truly broke I installed NoMad and was able to log in locally and remove the wifi, the other (first one I found today is an erase and install job as I hadn't seen the similarities at that point). May be a red herring but?

singletary
New Contributor III

That's an interesting data point. We also disable Wi-Fi on our affected iMacs and attempt to rely on the ethernet connection only.

kwarner
New Contributor

Hi, I know this is a bit of an old thread but we are starting to have this issue on some public-facing iMacs that are running anywhere from 15.3.2 to 15.4.1. My solution lately has been just to wipe the computers and reinstall with a clean MacOS image, but I wanted to see if you found a different solution?

Stuart_P
New Contributor III

Hi kwarner.  Are your devices bound natively to Active Directory?  That does seem to be a common thread here?

We are bound to AD, and using Jamf Pro to manage these macs and push automatic updates, etc.

singletary
New Contributor III

Still having some issues on our end but it's hard to say whether or not it is "fixed" because it only seems to arise during automated updates, and even then only on a small percentage of computers. I imagine we'll have to go through a few rounds of automatic updates without this happening before I'm feeling satisfied that I can stop monitoring our Macs for this busted state.

Kevm
New Contributor III

Hi Warner. We are still having the issues but so far everything I have erased and installed has been ok so far. I got called to one this week that only one user could not log in, after a reboot it was ok. I have been through every thought I had in desperation. What I have noticed that students who leave everything open (especially chrome with like 20 tabs open) are more likely to get the issues.. As discussed before though it seems to be down to a borked apple OS update. More about your environment would help. Do you use MDM, automatic updates, bound to AD etc?

kwarner
New Contributor

We use Jamf Pro to manage all of our macs, it's primarily maintained by a central IT department, and I'm in a sub-department so I don't have full access to change certain things. We also do push automatic updates and are bound to AD. We have 2 different AD binds, one for the public computers and one for staff, I haven't had any issues with the staff logins, but typically only one user is logging into those, rather than multiple per day.

Kevm
New Contributor III

That sounds familiar. Just out off interest are you able to log in with a local admin account when they go wrong? I rarely can.

It started for us around the 14.2 update and happens on MacOS15 too.but only after a DEP update for me.

When they do the freeze thing, I can always ssh into the Macs. Sometimes a quick fix can be after you have root ssh access 

sudo killall HUP  loginwindow 

wait a couple of seconds then

sudo launchctl start com.apple.loginwindow

sudo reboot.

occasional that fixes it.

Apple haven't supported using the directory utility for binding for years now so we are lucky it works at all.

I am going to erase and install all 700 of our Macs this summer if I get a chance. Currently looking at using different authentication methods too. Meanwhile I hope someone can find a fix.

kwarner
New Contributor

I rarely can login to the local admin account either.

I'm hoping for a break in student usage on the labs as a whole so I can just erase and install all of our macs as well. Hopefully this summer.

It does affect local accounts yes we can't log in with our admin account when machines get in this state but if I'm reading the other posts correctly this only seems to be affecting AD bound machines in general? As in no binding no problemo...