I found a terrible solution that works for us at this time. I'm thinking this is a gap that should be addresssed in the endpoint framework. Essentially if you create a daemon that uses the framework which runs under launchd, the app will get terimated on shutdown with no opportunity to unsubscribe, leaving the system hanging waiting on the app to respond. This is the message you will see in the log if you are fortunate enough to not completely deadlock the system:---------------------------------------------020-02-06 23:49:40.229877-0500 localhost kernel[0]: (EndpointSecurity) Client did not respond in appropriate amount of time (client pid: 121)2020-02-06 23:49:40.229924-0500 localhost kernel[0]: (EndpointSecurity) Client did not respond in appropriate amount of time (client pid: 121)---------------------------------------------My hacky solution is to intercept successful NOTIFY_EXIT events for a service that shuts down with the system and unsubscribe when I see that. This is likely to break between OS releases, so I very much appreciate advice on a longer-term fix...--------------------------------------------- if(msg->event_type == ES_EVENT_TYPE_NOTIFY_EXIT && msg->process->is_platform_binary && [@"com.apple.kextd" isEqualToString:esstring_to_nsstring(&msg->process->signing_id)] && msg->event.exit.stat == 0) { es_unsubscribe_all(g_client); LOG_INFO("Saw kextd exit"); }

Here is the gist of it...``` case ES_EVENT_TYPE_AUTH_SIGNAL: if(msg->process->is_platform_binary && [@"com.apple.xpc.launchd" isEqualToString:esstring_to_nsstring(&msg->process->signing_id)]) { return ES_AUTH_RESULT_ALLOW; } if([[NSProcessInfo processInfo] processIdentifier] == audit_token_to_pid(msg->event.signal.target->audit_token)) { return ES_AUTH_RESULT_DENY; } return ES_AUTH_RESULT_ALLOW;```

Hi eskimo. By "the app", I mean the user-space process that is receiving and responding to endpoint security events.