I'm using NSXPCConnection. (The extension is in fact written in Swift, since I figured that'd be better, although weirdly I still sometimes get a segfault.)

Ok! I will try that later today. Fortunately it seems pretty easy (famous last words 😄).

Ok. Just did a kill -9 of it, after adding     proxyManager.onDemandEnabled = YES;     NEOnDemandRuleConnect *connectOnDemand = [[NEOnDemandRuleConnect alloc] init];     connectOnDemand.interfaceTypeMatch = NEOnDemandRuleInterfaceTypeAny;     proxyManager.onDemandRules = @[         connectOnDemand,         ]; and it came back alive the next time I access the network.

Oooh, that does seem to have done it. Meanwhile, after a hospital scare involving my mother, I put in a bunch of log messages. (BTW: is there a better way to count open file descriptors than doing a readdir on /dev/fd? FreeBSD has kern.proc.nfds, but xnu doesn't seem to, and I didn't see a similar one from a quick search.) It is definitely being opened in the Security framework; however, I found that I was keeping a pointer to something using it when I only needed to get the pathname. (Specifically, I had a lazy var pathname; however, since that information was never going to change, I just set it during init, and am going to see if that helps. This does mean I seem to have a non-cleaned up flow somewhere, so I'll also have to look into that.)

You could try dispatch_after (using the main queue). However... none of the methods will ever be exact. A sleeping computer, for example, generally won't be running code in the background. And the OS scheduler is, ahem, complicated, and the load on the system can impact that.

Ouch, that is a much worse way to count open file descriptors: it takes N+1 system calls, where N is the limit (which could be a 64-bit MAXINT!). Compared to a readdir on /dev/fd, which is generally going to only be 3 or 4 system calls.

I had gotten confused because of rlim_t using 64-bit integers. Foolish on my part. I had in fact been increasing the process' number of file descriptors -- ironically because we'd been running out of file descriptors. I didn't need the paths, and without the Instruments version, I was calling my function... a lot ;). In reality it didn't matter, but I still hesitate at doing a few thousand system calls instead of just a handful. But thats because I am old, and date back to when a boundary crossing could take over a thousand cycles.

... There is virtually no documentation about propertiesRequest(forExtensionWithIdentifier:queue:). Since it takes a dispatch queue, I assume it returns a OSSystemExtensionRequest instance, and then I should set the delegate? And the delegate method -request:foundProperties: method will be invoked? Sorry I seem to have cross the Swift and ObjC streams in that. 😄

Also, yet another async call. 😄

I think that'll do. And how sad that Xcode can't :(.

You know I love the command-line. But jumping between the various tools is annoying. I may file a feature request for having Xcode be able to display provisioning details. There really is no reason it shouldn't be able to do that. Of course, there's also no reason Apple couldn't provide a tool that would explain exactly why a particular executable or bundle fails, and yet they don't...

If any of the Apple folk (hi Quinn :)) care, I filed FB9992060.

Oooh, so using security dump-trust-settings -s -d shows our certificate... but doesn't provide any actual information about it. This is a bit better than using security find-certificate -a | fgrep, but... is there a better way still? Ideally I actually want to see if the new certificate matches what's installed, and if so then do nothing.

haha self-deprecation is not allowed here, I see! :)

siiiiiiiiiiigh. The rest of the daemon I'd like to put this in is, of course, dispatch-based. I assume I can mix them both in, but I'll have to create a run loop just for this? It's been a long time since I've had to do run loop stuff.