launchd StartCalendarInterval behavior changed

This all makes me think that "sleep" on macOS in the past few years is now defined differently -- perhaps an Apple Silicon change? But I can't find documentation that covers this. Buried in a WWDC video, maybe?

I think it was before that. It sounds like you're encountering "Dark Wake". It's only hinted at in a couple of places in the documentation. The "Power Nap" feature is closely related and seems to be more openly acknowledged. But I don't know of any way (for an app) to detect or control when they get triggered. Apple engineers say there's no way to detect it.

Thank you for your insight - that's a good piece of the puzzle!

I found the DarkWake session: WWDC 2012, Session 711, "Power Management" with Ethan Bold and Soren Spies.

Sadly, I can't blame DarkWake because it has been around since 2012, but I only see this unexpected wake on newer macOS.
Since I'm using StartCalendarInterval on different versions, here's what I see:

• macOS 12 and earlier behave as expected; sleep through the CalendarInterval
• macOS 15 & 26 dark wake at the CalendarInterval

Perhaps Apple changed launchd to be capable of scheduling a dark wake. My guess is there is a Launch[Agent|Daemon] *.plist key that can be used to change this behavior.
I'll fire up BBEdit and go spelunking through /System/Library/LaunchDaemons/ to see if I can find a relevant key.

Of course, if this was documented, I wouldn't be left wondering if I should file a bug report!

Well I committed the cardinal sin of not eliminating enough variables before debugging. Time to set the record straight!

Here's what I learned:

• Above, I was wrong: in fact, macOS 26, 15, 12 (and earlier!) all DO exhibit this behavior: running a CalendarInterval scheduled job when MacBook is sleeping.
• The differentiator is not the OS version but the state of the lid -- lid open while asleep and you get the DarkWake behavior: launchd runs your job, it may still get suspended until a full wake
• Lid closed while asleep - behavior is as described here -- your job does not run in any way until the lid is opened
• I don't know what desktop Macs do here (no lid!).
• There is a PowerNap boolean key used by Apple in /System/Library/LaunchDaemons/ *.plists, but I wasn't able to suss out its behavior, and it only seems to be used in a com.apple.xpc.activity dictionary. If you'd like to give this a go for your own devices, dear reader, I wish you luck.

I was mis-attributing OS version to this launchd behavior, when it was actually that two of my test machines had different lid states. Mea culpa!

The title of this thread, therefore, should read "launchd StartCalendarInterval behavior depends on lid state"

And thanks again, Etresoft.

There are a bunch more factors in play here, including:

• For Macs with a battery, whether it’s connected to mains power or not.
• Various preferences in System Settings > Battery, and specifically those under Options.
• Lots of wacky options under pmset (see the pmset man page for more).

But these are all implementation details. From an API perspective, launchd doesn’t guarantee anything about the power state of the system when it starts your job based on StartCalendarInterval. Usually daemons aren’t expected to interact with the user, and thus it doesn’t really matter what the UI state of the system is when the system starts your job.

To offer more specific guidance here, I’d need to know more about what your job does.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I certainly don't mean to imply that the causal arrow points from launchd to power state; the opposite, actually! I'm just working to better understand Mac sleep.

(And yep, pmset -g is a fun little corner!)

The reason I am interested in the precise details of when StartCalendarInterval ends up running a job is that the available resources and limits of a Mac are different in these different power states.
I have to code with that in mind.

Re:my scheduled job I fear it will cause you fine and patient Apple folk to bristle, as its purpose is to work around Time Machine, uh, "changes" I have encountered. To wit:

"Time Machine did not finish backing up because some files were unavailable. Backups will resume when your Mac is unlocked." can be avoided by keeping the Mac awake and unlocked (caffeinate -d) during backup.

Time Machine *.sparsebundle "disk not ejected properly" errors can be prevented by using a script-assisted backup that verifies unmounting prior to sleep.

And I can speculate all day about changes to the SMB stack or whatever the root cause that makes my macOS 26 machine require 8 hours of trying to complete before it fails a backup, but I know that debug.lowpri_throttle_enabled=0 before backup gets me to a successful backup in about 2 hours.

SO, this particular job schedules a script that applies all of these workarounds, executes tmutil startbackup --auto --block, and cleans up afterward.

(And my apologies, I do realize this has strayed far from my posted topic/title. Thanks for reading =-)