Is the XPC interrupt handler called when launchd kills a process?

Question

The documentation for the interruptionHandler NSXPCConnection states:

An interrupt handler that is called if the remote process terminates or fails.

However, the Daemon and Services Development Guide says:

XPC services are managed by starting, which starts them on demand, restarts them if they fail, and terminates them (by sending SIGKILL) when they are not working. This is transparent to an application that uses this service, except in the case of a service that crashes while processing a message that requires a response. In this case, the application may see that its connection to the XPC has become invalid until the service is restarted at startup

If the XPC process is killed for being idle, will I get a callback in my interruptionHandler ? Or do I only get a callback when the application crashes while processing a message? I ask because this test case seems impossible to simulate. The life cycle of the XPC service is unfortunately a very black box.

Answer 1

Yes, an interrupt handler will be called if launchd stops the service for downtime.

This can be modeled by using a natural reaction launchd has a memory pressure: stopping all running running services that are idle to help fix the problem.

A simulated warning pressure level in your memory should be enough, here's how you do it:

 sudo memory_pressure -S -l warn 

And for critical:

 sudo memory_pressure -S -l critical 

This condition is often overlooked when testing XPC services. However, it is recommended that XPC services be inactive, so in most cases it does not matter if your service is stopped and can be restarted the next time you send a message at startup. And ideally, you canceled the connection the last time you were with him.

Launchd will not stop the XPC service with the above conditions if there is a current XPC transaction (read: message is being processed and / or the response block has not been called).