I have a use case in which I have a launch daemon (as the XPC service) than needs to communicate with two XPC clients. Each of these clients has different functional cases for communication that do not overlap. Therefore, the NSXPCInterface for client A would be configured with a different protocol than the NSXPCInterface that would be configured for client B. Client A and Client B do not need to talk to each other; they each just need to communicate with the daemon.
I am confused how to appropriately set up the NSXPCListener and NSXPCListenerDelegate on the daemon to support NSXPCConnections with proxy objects that adhere to varying interfaces to support these two clients.
Is there a way for a single NSXPCListener (and associated delegate) to listen for connections requiring the exportedInterface to be different?
Is there a way to send data through the NSXPCConnection that will allow the NSXPCListenerDelegate to conditionally determine which exported interface and object to configure?
One idea I had was to have the daemon contain two NSXPCListeners. Each listener would be responsible for connections coming from the respective clients.
Will this option work? If so, it is the advisable approach?
I'd like to get an indication about the context in which my process is running from. I'd like to distinguish between the following cases :
It runs as a persistent scheduled task (launchDaemon/launchAgent)
It was called on-demand and created by launchd
using open command-line or double-click.
It was called directly from command-line terminal (i.e. > /bin/myProg from terminal )
Perhaps is there any indication about the process context using Objective-c/swift framework or any other way ?
I wish to avoid inventing the wheel here :-)
thanks
Post not yet marked as solved
Hi,
In our system we have a launch daemon that manages a child process that performs networking. We also have launch agents that perform GUI work in each user session. We'd like those agents to connect to the child process of the launch daemon via XPC. In the launchd.plist we can expose a MachServices port for the launch daemon itself but how do we expose a port for the child process? Is it possible for the Launch daemon to smuggle a declared port to its child process?
Thanks!
Johan
Post not yet marked as solved
Hi,
We are creating a macOS application that is built as a 'Bundle' and NOT as a Unix-style application. In a specific flow, we need to attach this process to a terminal session by creating one. Now, on this attached terminal, stdin/stdout etc would happen.
We are using Objective C.
Any pointers on how to go about this would be helpful.
Post not yet marked as solved
I had my daemon service registered ( with keepalive true) to Mac OS and running in Catalina, after I upgraded to Bigsur the daemon did not start. when I tried to start manually I found that the daemon has been disabled.
I had to load the daemon service with '-w' to enable it. in a customer machine, we cant ask them to do it manually.
is there any way to stop disabling a daemon service during an upgrade to bigsur?
Hi, how could I get the command line arguments of a process given its audit token.
My app is a Content Filter Network Extension written in swift. I can obtain the audit token from NEFilterFlow but I can't figure out how to get the process arguments, I was able to get the pid from the audit token using audit_token_to_pid.
Post not yet marked as solved
I have a Safari Web Extension that communicates with its native App through UserDefaults within an App Group.
The WebExtensionHandler is also used to carry out other functions for the Web Extension on request.
I am currently troubleshooting a bug where a request from the Extension to the WebExtensionHandler remains unanswered.
The bug only occurs on physical devices, in the simulator, it always behaves as expected. When XCode is attached to the App or App Extension process, the bug also does not trigger. When the Console App is used to monitor events on the device, the bug also does not trigger.
Here is the code for the WebExtensionHandler:
import SafariServices
func respondWith(_ context: NSExtensionContext, string: String) {
let response = NSExtensionItem()
response.userInfo = [ SFExtensionMessageKey: string ]
context.completeRequest(returningItems: [response], completionHandler: nil)
}
class SafariWebExtensionHandler: NSObject, NSExtensionRequestHandling {
var sharedPrefs = UserDefaults.init(suiteName: "group.eu.waiyu.app")!
func beginRequest(with context: NSExtensionContext) {
let item = context.inputItems[0] as! NSExtensionItem
let message = item.userInfo?[SFExtensionMessageKey] as! Dictionary<String,Any>
switch message["type"] as! String {
// other cases...
case "get_config":
if let config = sharedPrefs.string(forKey: "config") {
respondWith(context, string: config)
} else {
let defaultConfig = message["defaultConfig"]!
respondWith(context, string: defaultConfig as! String)
}
default:
respondWith(context, string: "Unknown Message type")
}
}
}
Even though it appears that something goes wrong when accessing sharedPrefs when the bug is triggered, other requests are answered correctly (before and after triggering the bug).
As per some solutions to similar issues (https://stackoverflow.com/questions/38275395/failed-to-read-values-in-cfprefsplistsource-ios-10) I have tried different App Group IDs:
the main Bundle ID, prefixed with "group."
an ID different from both main bundle and extension bundle, prefixed with "group."
"group.TEAMID." prefix (TEAMID being the developer team id)
Is there anything I can try with regards to the code? Are there any other debugging workflows I can try that do not involve attaching to the device, that might allow me to capture more information about the bug?
I'm writing a Agent Application that records the Screen and I'm trying to keep the recording going even when the user logs out. I've been reading about LaunchAgents and LaunchDaemons. From what I understand a Prelogin LaunchAgent is my best bet since I need NSApplication to keep my process going and to access the screens. I'm only able to relaunch the app after login or to reopen the app when the os closes it. But the recording process is interrupted. Here is what I have as far as my LaunchAgent.
My prelogin LaunchAgent (to open the app during the LoginWindow context)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.myApp.prelogin</string>
<key>LimitLoadToSessionType</key>
<string>LoginWindow</string>
<key>RunAtLoad</key>
</true>
<key>ProgramArguments</key>
<array>
<string>/Library/myApp/myAgent0</string>
<string>service</key>
<array>
<key>QueueDirectories</key>
<array>
<string>/etc/myApp/service</string>
</array>
</dict>
</plist>
Per user launch agent (to keep the application open while a file exists in the path of QueDirectories)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.myApp.peruser</string>
<key>LimitLoadToSessionType</key>
<string>Aqua</string>
<key>RunAtLoad</key>
<true/>
<key>ProgramArguments</key>
<array>
<string>/Library/myApp/vmyAgent0</string>
<string>service</string>
</array>
<key>QueueDirectories</key>
<array>
<string>/etc/myApp/service</string>
</array>
</dict>
</plist>
And then a daemon that I was suggested to add.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.myApp.server</string>
<key>ProgramArguments</key>
<array>
<string>/Library/myApp/myAgent0</string>
<string>-service</string>
</array>
<key>QueueDirectories</key>
<array>
<string>/etc/myApp/service</string>
</array>
</dict>
</plist>
Currently the application get closed down when the user logs out and gets reopened when the user logs back in or every time I close it (until I remove the file from QueueDirectories). I'm not sure if it gets open during LoginWindow but I don't see any recordings of that so I don't think it does. I know it is possible since VNC viewer does it (you can remotely log into your Mac).
I'm not even sure I'm on the right track and I found this other question which tells me I'm on the wrong side using NSApplication for something like this? I'm in need of confirmations lol.
Thank you in advance.
I have small integration test that is confirming behavior in XPC communications (leveraging NSXPCConnection) between a dummy XPC service and an XPC client. My test is flaky, which is indicating to me that I don't fully understand the nature of connections between services and clients, and I was hoping to get clarity as to what's happening in my test.
My test involves the following steps.
XCode Pre-Action: Load the plist for a dummy XPC service into launchctl.
Create 2 XPC client objects (in the same client process), each with their own NSXPCConnection to the dummy service, and connect.
Tell client 1 to disconnect, which calls NSXPCConnection.invalidate()
Using client 2, send a message to the same dummy XPC service over it's own NSXPCConnection object.
Wait for the echo response from the dummy XPC service
XCode Post-Action: Unload the plist for the dummy XPC service from launchctl
func testMultipleConnections() {
let delegate1 = MockClientDelegate()
let delegate2 = MockClientDelegate()
let client1 = XPCMessagingClientFacade(withServiceName: serviceName, andXPCErrorHandler: {error in })
let client2 = XPCMessagingClientFacade(withServiceName: serviceName, andXPCErrorHandler: {error in })
client1.processMessageDelegate = delegate1
client2.processMessageDelegate = delegate2
_ = client1.connect()
_ = client2.connect()
_ = client1.disconnect()
delegate2.expectation = XCTestExpectation(description: "Message received from echo service")
_ = client2.sendMessage(ofMessageType: eMTAction_Uninstall, withData: ["dummy": "data"])
wait(for: [delegate2.expectation!], timeout: timeout)
}
This test sometimes succeeds and sometimes fails. Sometimes, the test expectation at the bottom is fulfilled, and sometimes the timeout is hit. I have tested with excessively long timeouts to rule-out processing-time as as factor.
I am suspecting that calling invalidate() on one NSXPCConnection object is somehow causing a separate connection between the same client and service process to also be invalidated.
Is it even a valid use-case to have multiple NSXPCConnection objects between a single XPC Service and XPC Client?
When NSXPCConnection.invalidate() is called, does it inherently mean nothing can connect and communicate anymore, or is it just for that specific connection?
When invalidate() is called, what does launchctl do to manage that service? Does it shut it down and allow subsequent connection attempts to spool the service up again? Does it prevent from any connections from ever being made again?
Post not yet marked as solved
I have LaunchDaemon plist launching a x86_64 daemon, which worked so far on my M1 Mac mini running Big Sur, but right after the reboot from upgrading to macOS Monterey, I see error launching with EBADARCH error, but when I load the same plist by hand it worked.
2021-10-27 10:23:15.602649 (system/com.[redacted] [530]) : Could not find and/or execute program specified by service: 86: Bad CPU type in executable:
2021-10-27 10:23:15.602661 (system/com.[redacted] [530]) : Service could not initialize: posix_spawn([redacted]) EBADARCH error: 0x6f: Invalid or missing Program/ProgramArguments
2021-10-27 10:23:15.602666 (system/com.[redacted] [530]) : initialization failure: 21A559: xpcproxy + 23196 [815][D33C7462-5256-38E5-AFD4-A1FF694581F3]: 0x6f
2021-10-27 10:23:15.602668 (system/com.[redacted] [530]) : Service setup event to handle failure and will not launch until it fires.
2021-10-27 10:23:15.602671 (system/com.[redacted] [530]) : Missing executable detected. Job: 'com.[redacted]' Executable: '[redacted]'
Post not yet marked as solved
I have an application that upon installation, registers a custom URL protocol (scheme) like foo:// using the lsregister command line tool.
Recently I noticed that the custom URL protocol is missing after an upgrade of macOS (Catalina to Big Sur). It appears that the upgrade de-registers the custom URL protocol while my application is still installed as it was before the macOS upgrade.Yet, any application functionality depending on its custom URL protocol is broken.
The only workaround seems to reinstall my application, or at minimum re-register the custom URL protocol manually.
Is this expected behavior for macOS upgrades? Do applications need to re-register any custom URL protocol again after a macOS upgrade? Why are these not retained as one would expect?
Post not yet marked as solved
Background
Alright, so there's a lot of voodoo and undocumented stuff going on here but hopefully somebody can help me out. I've reverse engineered how stuff might work based on:
https://opensource.apple.com/source/launchd/launchd-442.21/support/launchctl.c.auto.html
https://developer.apple.com/library/archive/technotes/tn2083/_index.html#//apple_ref/doc/uid/DTS10003794-CH1-SUBSECTION10
I've got a launchdaemon running that spawns another process in the /dev/console bootstrap context in order to act as a remote desktop server. What I'm trying to accomplish here, is to run one of my processes as root in the current gui bootstrap context which is attached to the console.
There are several guesswork states in MacOS (11.6, M1) that I've discovered. When you boot a machine, the loginwindow process is run in the bootstrap context of 88 (_windowserver). This makes sense because this process is created by WindowServer. The current console UID is discoverable by running:
echo "show State:/Users/ConsoleUser" | scutil
You can also introspect loginwindow using launchctl procinfo and friends.
Note that, this is before any login has ever happened on the machine.
In this state I can do anything in the gui bootstrap context by running this from the launchdaemon:
launchctl asuser 88 myprogram
In my case, I'm taking a screenshot using AppKit/CoreGraphics and checking some permissions.
Once a user logs in, that loginwindow gets blessed by the OS and ownership is transferred to the logged in user. If you lock the machine, you're still in the same bootstrap context and everything works as expected. You can also log out and log into another user and everything works as I expect it to in terms of who controls loginwindow.
However, as soon as you hit the "Switch user" button from the lock screen the following happens:
A new loginwindow is spawned with the bootstrap context of root (UID of 0)
launchctl asuser 0 myprog seems not to properly execute within the bootstrap context of root.
My guess is that: 1 is a bug(?), the fast user switching bootstrap context should probably run as 88 rather than 0.
A "fix" is running pkill loginwindow which nukes all gui sessions and restarts one loginwindow running in the bootstrap context of 88. This is of course not an acceptable solution.
Doing the same thing using launchctl bootstrap gui/0 doesn't work either. I understand that the concept of "bootstrap gui/0" and "asuser 0" sounds nonsensical and it probably is. I'm just trying to find a working solution here.
Is there a more proper way of being able run as root in the bootstrap context of a logged in/not yet logged in loginwindow?
In case anyone is curious, I'm porting this to MacOS: https://fleetdeck.io
Post not yet marked as solved
Hello,
We created a sample app delegate to test whether applicationDidFinishLaunching runs as expected or not (code as follows). The observed behavior was that the executable
prints both applicationWillFinishLaunching and applicationDidFinishLaunching in the case when we're using an RDP connection to the mac
prints only applicationWillFinishLaunching in case of ssh connection to the mac
Why is this behavior different and how can I ensure it runs correctly with ssh? Kindly help.
#include <unistd.h>
#include <sys/types.h>
#include <Foundation/Foundation.h>
#import <Cocoa/Cocoa.h>
#import <SystemConfiguration/SystemConfiguration.h>
#import <SystemConfiguration/SCDynamicStore.h>
@interface TWAppKitAppDelegate : NSObject <NSApplicationDelegate>
@end
@implementation TWAppKitAppDelegate
// Launching Applications
- (void)
applicationWillFinishLaunching: (NSNotification *) pNotification
{
NSLog(@"applicationWillFinishLaunching");
}
- (void)
applicationDidFinishLaunching: (NSNotification *) pNotification
{
NSLog(@"applicationDidFinishLaunching");
}
// Managing Active Status
- (void)
applicationWillBecomeActive: (NSNotification *) pNotification
{
}
- (void)
applicationDidBecomeActive: (NSNotification *) pNotification
{
}
- (void)
applicationWillResignActive: (NSNotification *) pNotification
{
}
- (void)
applicationDidResignActive: (NSNotification *) pNotification
{
}
// Terminating Applications
#if 0
- (NSApplicationTerminateReply)
applicationShouldTerminate:(NSNotification *) pNotification
{
return NSApplicationTerminateReply::NSTerminateNow;
}
#endif
- (BOOL)
applicationShouldTerminateAfterLastWindowClosed:(NSNotification *) pNotification
{
return NO;
}
- (void)
applicationWillTerminate:(NSNotification *) pNotification
{
}
- (BOOL)
application:(NSApplication *) pSender
openFile: (NSString *) pFileName
{
return YES;
}
- (void)
application:(NSApplication *) pSender
openFiles: (NSArray<NSString *> *) pFileNames
{
}
@end
int
main (int pArgc, char ** pArgv)
{
NSApplication * app;
TWAppKitAppDelegate * appdelegate;
app = [NSApplication sharedApplication];
appdelegate = [[TWAppKitAppDelegate alloc] init];
[app setDelegate:appdelegate];
[NSApp run]; //NOTE: Apple never 'returns' from here
NSLog(@"Function main called \n");
return 0;
}
Post not yet marked as solved
I’m trying to implement a simple cross-process notify/observe system, using a pthread mutex and condition variable in shared (mapped) memory. It seems to be working fine (on macOS 11.6) if one process calls pthread_cond_wait and then another calls pthread_cond_broadcast — the waiting process indeed wakes up.
However, if two processes try to observe at the same time, the second one's call to pthread_cond_wait fails with EINVAL. I’m wondering if I’m just doing something wrong in my setup, or if this sort of usage isn’t supported.
Basically I create and mmap a file, initialize a pthread mutex and condition in the mapped memory using the setpshared attributes, then lock the mutex and notify or wait on the condition. Actual source code here:
Here’s the code that does the pthreads stuff
Here’s the outer code that opens and mmaps the file
I’m aware that there are a few dozen 🙄 Apple IPC APIs that are probably preferred over these POSIX ones. I’ve used some in the past. I’m doing it this way because:
(a) this is in a cross-platform project and it would be nice to share code between Unix platforms, at least Darwin and Linux;
(b) the thing I’m notifying/observing about is a database file, so tying the notifications to a side file next to the database provides ideal scoping;
(c) it’s similar in principle to the usage of shared memory for locking in SQLite and LMDB. (The difference is, I’m doing notification not locking.)
Any advice?
—Jens
Post not yet marked as solved
I have written C software that makes extensive use of shared memory (200MB using shmget, etc.), which compiled and ran on Mojave and Linux. Using this shared memory required /etc/sysctl.conf to increase the buffer sizes during OSX boot. It appears that Catalina no longer uses my /etc/sysctl.conf file, whether SIP is enabled or disabled. Now the software compiles but fails to run, because the default shared memory size (4MB) is too small on Catalina. How do I specify the shared memory parameters to increase above the default in Catalina?
kern.sysv.shmmax=268435456
kern.sysv.shmmin=1
#kern.sysv.shmmni=128
kern.sysv.shmseg=32
kern.sysv.shmall=65536
Post marked as Apple Recommended
How do I access a returned value from a Process(), in this case 'which'... var sips_path : String? //MARK: locate sips on local machine let which_sips = Process() which_sips.executableURL = URL(fileURLWithPath: "which") which_sips.arguments = ["sips"] do { sips_path = try which_sips.run() } catch let error as NSError { sips_path = "/usr/bin/sips"; print("Failed to execute which_sips", error) }line 8. gets compiler error "Cannot assign value of type '()' to type 'String?'" I believe, but cannot prove, 'which' returns a string. .run() throws and throws are for errors only, right? So where is the result of calling which?It seems I should use a closure to use $0 but it's already in one...line 9. intends to assign a default path.
Post not yet marked as solved
Hello -
TLDR - Is there any sample code to demonstrate how one goes about creating dedicated XPCServices to wrap ARM and Intel-specific dylibs?
We have an app we're looking at moving to a universal binary.
In that same app we have a framework that currently wraps R functionality by directly linking to /Library/Frameworks/R.framework/Current .
R now has dedicated Intel and ARM builds (https://mac.r-project.org/)
After watching the 2020 WWDC session "Port your Mac app to Apple silicon" (https://developer.apple.com/videos/play/wwdc2020/10214/?time=2006), it sounds like, for us to deploy a universal binary I should look at wrapping the R interaction bits into dedicated ARM and Intel XPC services so the appropriate architecture for R will run.
Is anyone aware of any sample code or extended documentation demonstrating the ins and outs of how to think about this?
Thank you
Post not yet marked as solved
Running a child process using Process (or NSTask in Objective-C) is easy, but piping data to and from the child’s stdin and stdout is surprisingly tricky. I regularly see folks confused by this. Moreover, it’s easy to come up with a solution that works most of the time, but suffers from weird problems that only show up in the field [1].
I recently had a couple of DTS incidents from folks struggling with this, so I sat down and worked through the details. Pasted below is the results of that effort, namely, a single function that will start a child process, pass it some data on stdin, read the data from the child’s stdout, and call a completion handler when everything is done.
There are some things to note here, some obvious, some not so much:
I’ve included Swift and Objective-C versions of the code. Both versions work the same way. The Swift version has all the comments. If you decide to base your code on the Objective-C version, copy the comments from there.
I didn’t bother collecting stderr. That’s not necessary in many cases and, if you need it, it’s not hard to extend the code to handle that case.
I use Dispatch I/O rather than FileHandle to manage the I/O channels. Dispatch I/O is well suited to this task. In contrast, FileHandle has numerous problems working with pipes. For the details, see Whither FileHandle?.
This single function is way longer than I’d normally tolerate. This is partly due to the extensive comments and party due to my desire to maintain focus. When wrapping Process it’s very easy to run afoul of architecture astronaut-ism. Indeed, I have a much more full-featured Process wrapper sitting on my hard disk, but that’s going to stay there in favour of this approach (-:
Handling a child process correctly involves some gnarly race conditions. The code has extensive comments explaining how I deal with those.
If you have any questions or comments about this, put them in a new thread. Make sure to tag that thread with Foundation and Inter-process communication so that I see it.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
[1] Indeed, this post shows that I’ve made this sort of mistake myself )-:
Post not yet marked as solved
I'm opening a different thread to a question that was asked about a year ago.
I'm trying to get the output of "which" so that I can automatically find programs for the user. I've used the code that was provided in that thread which is:
func launch(tool: URL, arguments: [String], completionHandler: @escaping (Int32, Data) -> Void) throws {
let group = DispatchGroup()
let pipe = Pipe()
var standardOutData = Data()
group.enter()
let proc = Process()
proc.executableURL = tool
proc.arguments = arguments
proc.standardOutput = pipe.fileHandleForWriting
proc.terminationHandler = { _ in
proc.terminationHandler = nil
group.leave()
}
group.enter()
DispatchQueue.global().async {
// Doing long-running synchronous I/O on a global concurrent queue block
// is less than ideal, but I’ve convinced myself that it’s acceptable
// given the target ‘market’ for this code.
let data = pipe.fileHandleForReading.readDataToEndOfFile()
pipe.fileHandleForReading.closeFile()
DispatchQueue.main.async {
standardOutData = data
group.leave()
}
}
group.notify(queue: .main) {
completionHandler(proc.terminationStatus, standardOutData)
}
try proc.run()
// We have to close our reference to the write side of the pipe so that the
// termination of the child process triggers EOF on the read side.
pipe.fileHandleForWriting.closeFile()
}
it works fine for all of the normal command line routines but not for custom ones such as avr-gcc or any other that is installed via homebrew. I can use "which avr-gcc" in terminal and it shows the path just fine but in my app it returns nothing where as if I search for the path of something like ls in my app it returns it just fine.
What could be the cause of this?
Post not yet marked as solved
I've got an mach-o executable that runs from launchDaemon plist file, and is communicating with other processes using unix domain socket. The file that backs this socket created in /tmp. However, this cause the executable to fail reading the file unless given full disk access.
I'd like to find a location for the socket file, which is shared to all processes and doesn't require full disk access. the executable reside in /Library/Application Support/myProj/bin/exec_file
is there such location ? Perhaps can i use the same location of the executable itself ?
mackers.
