FB8077665

FB8077645

After some additional attempts, it looks like that: its' possible. the name of the Mach service needs to be prefixed with the team identifier and the app group/hosting app prefix.

OK, I will file a report when the feedback server is back online. I will also add a comment in my code to not be surprised the day the define is back in the header and this creates a conflict with the one I had already defined. I guess your answer implies that we should use the userland frameworks.

For the record, if you move from a Data Filer only extension to a Data and Packet Filter extension, a restart of the Mac might be required. That's what I've observed so far when updating the SimpleFirewall sample project. But at the same time, the system extension manager seems very fragile when it comes to installing/uninstalling, starting and stopping network extensions. So, in theory, a restart may not be required.

In Console.app, check also for the errors reported by sysextd. It's possible to implement it in Obj-C. I've just succeeded in seeing the first bytes in an Obj-C implementation after going through a lot of issues mainly related to bundle identifiers, app ids, app groups, xpc names, extension name. Naive (b/c the other word is censored) question: is the System Extension listed as running in the System Preferences > Network pref pane?

Thanks. Will look into the updated documentation, it seems quite good.

Observing the same issue here while trying to debug the SimpleFirewall Project. It would be nice if the SimpleFirewall sample project was updated with instructions on how to: build it (the instructions provided in another thread (entitlement, developer profile, app IDs) seem to be working but could be a bit more detailed). run it. debug it (not the app but the System Extensions).

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.

> 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.

Front-End: there can be only one instance of pFE running (via the LSMultipleInstancesProhibited Info.plist key).The other process pO that can launch the daemon pLD is either a launchd agent or another launchd daemon.Supporting multiple front-ends would definitely be the solution but that would require to revisit a good part of the UX. And anyway I would still need to know whether pLD is running to avoid enabling the appropriate push button in the UI (otherwise this would end up with a Windowsish UI where you click on an enabled button and you are told that this action can not be performed because it has probably been already been triggered by another process).As I somehow mentioned, I could still send a XPC message to the daemon to know what it's currently doing. But that could result in launching it and launching it would create useless disk activity and consume CPU resources to initialize the daemon to terminate it almost immediately.

Yes, pFE or pO sends a XPC message to pLD XPC listener to do something and launchd will launch it if it's no already running.

Are you suggesting to parse the output of launchctl list (*) and check whether there is a pid for the appropriate label?From what I'm quickly seeing, it requires to execute the command as root. * or check the open source implementation and do it more reliably.

OK, let's call this closed clamshell mode if this is the official name.In the case I'm describing there is a screen (the Screen Sharing.app window on the other Mac) to show them. Otherwise I wouldn't notice they are not displayed.I understand your argument but then if we follow your logic, why would there be something displayed in the Screen Sharing.app at all then?

> Why do you want to do this?I have 3 processes (launch daemon : pLD, Front-End: pFE and another process : pO).pLD can be launched either by pFE or pO.If pO launched pLD, when pFE is launched, it should display a modal alert informing that pLD is running and that pFE will quit. Also pO can not launch pLD if pFE is running as usual.Unfortunately NSRunningApplication API is not part of Foundation and not powerful enough to handle this.