How to avoid "Pushing respawn out by y seconds"?

I have an app and a launchd daemon.


- The app communicates with the launchd daemon through XPC.

- The launchd daemon is triggered by the XPC "message" and exits after having completed its task.


Problem:


When I repeatedly launch the app, launchd is not happy with the fact that the daemon only runs for around a second and starts complaining in system.log with:


Service only ran for 5 seconds. Pushing respawn out by 5 seconds.

Service only ran for 7 seconds. Pushing respawn out by 3 seconds.


And sure enough launching and getting an answer from the launchd daemon is delayed at some point.


Question:


Is there a key to put in the launcdh plist file or a function to call from the launchd daemon to explain to launchd that this is the expected behavior for the daemon and that it should not delayed its next launch?


I've checked the launchd.plist man page but have not found anything enlightening so far.

The launchd daemon is triggered by the XPC "message" and exits after having completed its task.

Why does your daemon exit?

Our standard advice for daemons is that they park themselves (preferably using

dispatch_main
) waiting for the next IPC request. The system will stop the daemon if it needs the memory.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

> Why does your daemon exit?


Multiple reasons:

a. to avoid any potential complains from launchd that the daemon is always running and that this is inefficient. Maybe it does not display this for XPC-triggered daemons but this is not clearly documented AFAIK.

b. to avoid having the daemon listed in the Activity Monitor while it's doing nothing.

c. because there might be up to a 4-day interval between 2 tasks performed by the daemon.

d. because I can't be a 100% sure at this time that when the daemon has completed the task requested by the XPC message, the daemon is correctly reverted to its original idle state.

I don’t find any of your reasons compelling. Our recommendation is that you not idle exit your daemon but instead opt in to pressure exits. See the discussion of

EnablePressuredExit
in the
launchd.plist
man page and specifically this quote:

Jobs seeking to exit when idle should use the

EnablePressuredExit
key to opt into the system mechanism for reclaiming killable jobs under memory pressure.

If you choose to ignore that advice then your next best option is to slightly increase the idle exit timeout you use. The default

launchd
throttle interval is 10 seconds, so you should be fine if you idle exit after a minute.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Don't worry, I don't find any of these reasons compelling either, since they are all external:

- rare case of end users complaining about the names of the processes or that they are listed when they are doing nothing.

- legacy code and architecture.

- launchd mysteries.


I will check

EnablePressuredExit.

Hello. Im a few years late, but I'm trying to set up a custom LaunchAgent file in ~/Library/LaunchAgents/ to run a .sh file when the bluetooth state changes (the .sh file then changes the audio input device based on the bluetooth device that just connected, but thats beside the point). Ive got it set up and working, but have run into this exact issue now.

After reading Quinn's response, I wonder if I'm going about this the correct way. If using a custom LaunchAgent isn't the recommended way to achieve something like this, how should I go about it as so far all of the information I've found on other forums (main inspiration from https://apple.stackexchange.com/questions/332434/how-can-i-trigger-an-applecript-or-automator-app-when-a-specific-bluetooth-devic ) has pointed me towards custom LaunchAgents

How to avoid "Pushing respawn out by y seconds"?
 
 
Q