We have an application written mainly in Obj-C that supports users starting from MacOS 10.7
The app had a couple of targets that are comman-line tools.
The command line tools need to communicate with main app at the moment using distrubuted objects .
Is there a way to introduce XPC services into the command line tools so that we can move to modern comunication api's with XPC or do we somehow need to "transform" the command-line tools daemons into XPC Services target ?
In what context do these command line tools run? Reading your text it sounds like they run in the user’s context, but your subject line is “XPC Services for a daemon”, and a daemon implies execution in a global context.
So, are you creating a daemon? Or are you just using the term “daemon” in the wider sense of a process without a UI?
FWIW a launchd daemon can easily support XPC via the
MachServicesShare and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"In what context do these command line tools run? Reading your text it sounds like they run in the user’s context, but your subject line is “XPC Services for a daemon”, and a daemon implies execution in a global context.
You are correct, by daemon all I meant is that the target its a non UI command line written in Obj-c running in the users context, its controlled by launchd user agent for starting and in case of command line crash to restart. Eventually it will run ias an execution in a global context but we are not there yet.
So, are you creating a daemon? Or are you just using the term “daemon” in the wider sense of a process without a UI?
Just using term for process in Obj-C without UI
FWIW a launchd daemon can easily support XPC via the
MachServicesJust to clarify, what you are stating is that we can add the XPC services to a process without UI even if the process is a command line tool and not an XPS Service ? So far what we have tried is to add the NSXPCConnection API to the command line tool and created an Info.plist for that command line but it always crashes on [listener resume]; We have followed the documentation and are scratching our heads around it. What you are suggesting is that instead of adding an Info.plist is to instead add the XPS service properties to the launchd plist that is deployed with the command line to control it and that lives in ~/Library/LaunchAgents/com.myApp.myCommandLine.plist ?
To start, I recommend you read Technote 2083 Daemons and Agents. It somewhat out of date these days, but it defines a bunch of terms that I’m going to use without explaining.
launchd daemons and agents can publish services in the appropriate Mach bootstrap namespace (global for a launchd daemon, GUI per-session for a launchd agent unless you override that using the
LimitLoadToSessionTypeMachServices-[NSXPCListener initWithMachServiceName:]Once that’s set up a client can connect to the service using
-[NSXPCConnection initWithMachServiceName:options:]IMPORTANT If the service is registered in the global namespace (that is, you’re talking to a launchd daemon), pass in the
NSXPCConnectionPrivilegedIf you’re eventual goạl is to move this service to a launchd daemon then my recommendation is that you simply set up a launchd agent as described above and then go from there. There are lots of other things you can do if you have more complex requirements, but this is a good start.
ps Please drop me a line via email (my address is in my signature), making sure to quote this thread for context.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
Unfortunately our developer documentation no longer includes man pages (r. 16512537), so I can’t simply update the link )-: I now reference man pages using this syntax: launchd.plist man page. Post back if you have troubles accessing it that way.the launchd property list link is dead... could you please update
it?