I knew I had a reason for wondering about others, but I think that was just curiosity. The issue I'm trying to deal with is having the transparent proxy not come back automatically; I had thought I could use a daemon we have to try to start the VPN if it was not connected, but I'm not sure that is possible. (After the containing app loads the extension; the reason to see if it's already loaded is to send a message off to an agent, which would then open a url to cause the containing app to launch and load.)

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! :)