Intermittent login issues on macOS 15.1.1

Thanks ​@gingadmin That's interesting, what I was using previously was 

sudo killall HUP loginwindow

sudo launchctl start com.apple.loginwindow

sudo reboot

This didn't always allow the user to log on but it often got the local admin account back in.

I will try that, first I have to work out how to re enable ssh on 700 Macs after a rebuild with a script.

I’ve been given a Mac mini that is experiencing this issue after upgrading to macOS 26 and there definitely feels like there is something odd gong on with the com.apple.backgroundtaskmanagementd daemon.

If I try to stop it via SSH at the login screen, as suggested, I receive…
 

# launchctl bootstrap system /System/Library/LaunchDaemons/com.apple.backgroundtaskmanagementd.plist

Bootstrap failed: 5: Input/output error

#######

The status of the daemon is “-9” whilst EVERYTHING else is 0 or 1…
 

# launchctl list | grep background

- -9 com.apple.backgroundtaskmanagementd

#######

As this is a system Daemon there is little control over it.  Has anyone else got anywhere with this???

Stuart

################

EDIT

Having looked at the launchd.log (and filtering it for “background”) I seem to have lots of entries like the below so it feels like it is trying to launch something and it is very quickly using far too much RAM and exiting.  How do we then track down what sub-process the backgroundtaskmanagement daemon spawns that use too much memory?

2025-09-26 10:20:17.857197 (system/com.apple.backgroundtaskmanagementd) <Notice>: service state: spawning
2025-09-26 10:20:17.857273 (system/com.apple.backgroundtaskmanagementd) <Notice>: launching: ipc (mach)
2025-09-26 10:20:17.859345 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: xpcproxy spawned with pid 867
2025-09-26 10:20:17.859375 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: internal event: SPAWNED, code = 0
2025-09-26 10:20:17.859383 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: service state: xpcproxy
2025-09-26 10:20:17.859396 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: deferred event: domain spawn response: 0
2025-09-26 10:20:17.859410 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: internal event: SOURCE_ATTACH, code = 0
2025-09-26 10:20:17.872589 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: service state: running
2025-09-26 10:20:17.872611 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: internal event: INIT, code = 0
2025-09-26 10:20:17.872647 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: Successfully spawned backgroundtaskmanagementd[867] because ipc (mach)
2025-09-26 10:20:17.880333 (pid/867 [backgroundtaskm]) <Notice>: uncorking exec source upfront
2025-09-26 10:20:17.880369 (pid/867 [backgroundtaskm]) <Notice>: created
2025-09-26 10:20:18.084717 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: exited with exit reason (namespace: 1 code: 0x7) - JETSAM_REASON_MEMORY_PERPROCESSLIMIT, ran for 226ms
2025-09-26 10:20:18.084738 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: service state: exited
2025-09-26 10:20:18.084750 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: internal event: EXITED, code = 0
2025-09-26 10:20:18.084756 (system) <Notice>: service inactive: com.apple.backgroundtaskmanagementd
2025-09-26 10:20:18.084804 (system/com.apple.backgroundtaskmanagementd [867]) <Notice>: service state: not running
2025-09-26 10:20:18.084819 (system/com.apple.backgroundtaskmanagementd) <Notice>: Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
2025-09-26 10:20:18.084921 (system/com.apple.backgroundtaskmanagementd) <Notice>: internal event: WILL_SPAWN, code = 0
2025-09-26 10:20:18.084925 (system/com.apple.backgroundtaskmanagementd) <Notice>: service state: spawn scheduled
2025-09-26 10:20:18.084927 (system/com.apple.backgroundtaskmanagementd) <Notice>: service spawn deferred by 10 seconds due to throttle
2025-09-26 10:20:18.125998 (pid/867 [backgroundtaskm]) <Notice>: shutting down
2025-09-26 10:20:18.126020 (pid/867 [backgroundtaskm]) <Notice>: cleaning up

OK - so having spent a lot of time on this today I can confirm the following.

On a Mac that is having issues you can run the following command at the login screen via SSH and if the return contains “-9” then it’s in a bad state and running the following commands resolves it…
 

launchctl bootout system/com.apple.backgroundtaskmanagementd

launchctl bootstrap system /System/Library/LaunchDaemons/com.apple.backgroundtaskmanagementd.plist

When you start to login the daemon returns to error “-9” and re-running the two commands above seems to allow the login to go straight through.

This is scriptable but it effectively needs to be run as a Launch Daemon to work and this is the thing that is broken.

I have cleared out all of the non-system Daemons and Agents and it still doesn’t work so it doesn’t feel like it’s something that we’ve done but the backgroundtaskmanagement daemon seems to exit after consuming too much memory when sat at the login screen.  I need to do some checks on some “good” Macs to see if there is anything different.  Stopping and starting the background task Daemon does appear to have negative effects though so I’m not sure if this is viable to become art of any solution but it’s definitely further than I’ve been before.  It just feels as though there something that it’s trying to load that is broken.

Hi Stuart, I get an error on the first line 

Boot-out failed: 150: Operation not permitted while System Integrity Protection is engaged

do you have sip disabled?

Ah - I did disable it yes, as part of testing.  It’s not something I’d want to leave disabled so that stops that being particularly useful...

You can delete that background .btm file that gets created and it will resurrect a device for a time so for the time being we are just deleting the file on every boot until Apple support get back to us to say there’s a fix in the pipeline.

Hi allanp81,

CAn you provide some more information on this if you have a work-around?!?  What is this .btm file and where is it found?

Thanks

Stuart

In /var/db/com.apple.backgroundtaskmanagement there will be a file (I’ve occasionally seen multiple files) called BackgroundItems-v13.btm or something similar (I’ve seen v9 and v16 for instance).

If you delete this file via recovery mode it brings a dead Mac back to life on next reboot. I’m just actively deleting this file on boot for the time being until Apple can offer a proper fix.

Many thanks, I can confirm that deleting these files works! I’ve made a policy to just get rid of them every check in (doesn’t seem to have any ill effect if the machine is logged in) and in testing this has un-stuck stuck machines reliably. This is a huge help hopefully Apple will fix this in due course but for now this will keep us going.

Ian

I found that deleting it while a user is logged in doesn’t seem to work, the file reappears shortly the after in the same form as the deleted file, presumably because it’s being kept in memory.

I have tested this work-around on one Mac Mini and it seems to have worked.  Good timing, we’ve had another case raised, just today, for the issue having returned to X No. of PCs in one of our labs so we will test this wider shortly.

Thanks ​@allanp81 Out of interest, how did you come to this work-around?

@Stuart there’s numerous threads on the Slack macadmins and someone seemingly randomly raised that deleting that file fixed it, I have no idea how they figured it out as I’d tried everything and been going back and forth with Apple support for the best part of a year trying to work out what the fault was.

I just tried this (SIP) enabled and it worked  over ssh , tried it previously and it didn't. Thanks for this.

rm -rf /private/var/db/com.apple.backgroundtaskmanagement/*

I might make a script to run this on start up too.

The way I understand this issue (possibly incorrectly)…

If you go ahead and delete the *.btm files from a live system where the “backgroundtaskmanagement” daemon is working, this won’t accomplish anything as the cache is in memory and the files will get written back, almost immediately, with little or no change.

Deleting them from recovery is a work-around as the service isn’t loaded.

Maybe deleting them via SSH on a broken system works as the “backgroundtaskmanagement” daemon is not able to start so the cache is not in memory.  However, the fact that the “backgroundtaskmanagement” daemon is not starting makes it hard to script on a broken system.

Maybe having a script that stops the “backgroundtaskmanagement” daemon, deletes the *.btm files, and restarts it again will work but I haven’t had a chance to try to throw one together to see if it would be possible or if it would have any negative impact to the system.

For now we’re just taking it as a manual work-around when the issue presents.

It’s probably worth noting that we’ve also found this same work-around helps for an issue on our Intel-based Macs that we thought was a different problem to the M1 / 2 / 3 / 4 devices where a percentage of devices just seem to start rebooting after 2-3 minutes when sat at the login screen or during user login.

Just to add we did try sticking Tahoe on a machine that had this issue in case that magically fixed it which it didn’t so I think the problem persists in MacOS 26 and has been brought over from 15. Whether it’s any different if it’s a fresh install I don’t know this was a music production computer with a lot of manual setup on it so we were keen to avoid flattening it.

The policy I have running on check it to clear the files does seem to have calmed this down a lot although it is filling up the policy logs on everything!

I think we have seen this issue now across macOS 14, 15 and 26.  It certainly doesn’t feel like it’s OS-restricted, especially if Apple don’t know why it’s happening.

I am going to test this script to reload the bgtaskmanagementd on launch when I get chance.

Its not my work, created by AI.

#!/bin/zsh

if /bin/launchctl help 2>&1 | /usr/bin/grep -q bootout; then echo "$(date +'%F %T') — using bootout/bootstrap" >> "$LOG"

/bin/launchctl bootout system "$PLIST" >> "$LOG" 2>&1 rc=$? echo "$(date +'%F %T') — bootout rc=$rc" >> "$LOG"

sleep 2

/bin/launchctl bootstrap system "$PLIST" >> "$LOG" 2>&1 rc2=$? echo "$(date +'%F %T') — bootstrap rc=$rc2" >> "$LOG" else echo "$(date +'%F %T') — using unload/load fallback" >> "$LOG"

/bin/launchctl unload "$PLIST" >> "$LOG" 2>&1 rc=$? echo "$(date +'%F %T') — unload rc=$rc" >> "$LOG"

sleep 2

/bin/launchctl load "$PLIST" >> "$LOG" 2>&1 rc2=$? echo "$(date +'%F %T') — load rc=$rc2" >> "$LOG" fi

echo "$(date +'%F %T') — completed bgtaskmanagementd reload" >> "$LOG"

exit 0

I set it to delete the file on boot, so far I think it’s working.

How have you achieved this?  If done via a Jamf policy then my understanding is that this may not work as it would rely on the thing working that you are trying to fix.  I say this as I noted that Jamf policy deployments seemed to rely on the backgroundtaskmanagement daemon.

I have tested deleting on boot with Filewave and it works, haven't deployed widely yet but it is on one of my test groups to monitor. That script above was in case deleting has a negative effect. In the brief testing so far, the files in that folder are recreated when needed.

We use outset which has a “Boot-every” and “Boot-once” feature.

Having an actual file to look at was super helpful.  Deleting it fixes broken machines for us.

Looking at the file from a broken machine - I think our issue is just that it’s getting too big.  You can see what’s in it on a working machine with ‘sfltool -dumpbtm’.  

https://support.apple.com/en-gb/guide/deployment/depdca572563/web

Our file from a broken machine had 55 things each for 120 users.  With all the overhead, that means thats an NSKeyedArchiver archive with like 40,000 elements, which then meant the resulting .btm file was a 4MB binary plist with 150,000 objects.

These are general access computer lab machines and we have a bunch of software on them and delete the user accounts (probably not the proper way) after a couple days - so they were probably just hitting a threshold after some particular number of unique users logged into the machine.

We’ll probably just run ‘sfltool -resetbtm’ as part of our boot scripts or something to clear things out periodically and see if that fixes things in a couple months.

---

Now… - interestingly and I suppose mostly for Apple’s benefit.  I ran plutil -convert on the .btm file that was breaking my machine to convert it to xml and back to binary as part of poking around, and the resulting binary plist was half the size, and didn’t cause the login to hang.

Which took me down a rabbit hole of writing my own bplist parser to figure out what the heck was going on there - seems like the .btm file is perfectly legit binary plist, it’s just really poorly compressed and has a ton of unreferenced orphaned data in it.  Which - may be them optimizing for speed vs size or something, who knows.

Regardless - seems like it’s not strictly an issue with too many background tasks in the file due to x users times y tasks.  It’s maybe more of a parsing error of some sort if the file is too large

After a bit more poking… - I have not been able to recreate the issue simply by creating .btm files of a similarly large size.  Creating new binary plist with all the stuff in the broken one does seem to yield a working one, but as far as I can tell, the broken one isn’t corrupted or anything.  So it’s something about the particular binary plist encoding that it doesn’t like beyond just the overall size / object count - which I suppose Apple will have to figure out.

So unfortunately, I guess I can’t yet say for certain that resetting it will fix the issue without tracking down a bunch of other broken machines to see if the file is always similarly large for them.  But still seems like it probably couldn’t hurt and Ima try it.

Interesting.  I’m not at my managed Macs right now but can you see that running “sfltool -resetbtm” on a working Mac does indeed reset the files, live?  I ask as deleting them from a live system doesn’t seem to work but using the sfltool is probably (almost definitely) a better way to work with the live files.  Just thinking, as you mentioned, above, that we could run this once a week or every few days on our lab Macs to try and be as preventative as possible.

Thanks

Yes, it does reset the file live.  So almost certainly better than just deleting it if you’re trying to run something periodically I’d imagine.

If the issue isn’t strictly related to the size of the file, I don’t know if that would actually prevent things necessarily, but I’m currently guessing it is.

Not sure if there is a way you could use that to fix a broken machine.  Doesn’t seem like our startup/login scripts or management tools are especially running on the broken ones.  People above mentioned being able to ssh into broken ones, but we don’t have that set up.  Could maybe run it that way.​​​​  But no idea if it’d still work and actually reset anything if the machine is already in the broken state.