use of daemon call in ported code

daemon(int nochdir, int noclose) is marked as discouraged.

Will it work in straight unix ported code that doesn't use Apple libraries?

I wrestled with this discouragement in a previous life where I had to gradually shift calls to CF to one side of deamon or the other in order to prevent catastrophe.

The cost of moving to launchd as is non-trivial in this instance and I'd like to be sure it is going to be necessary before going farther down this path.
Up vote post of joconnor Down vote post of joconnor
716 views
Posted by
joconnor
Reply
Add a Comment

Accepted Reply

I got things working with dispatch and xpc, so this question isn't really relevant any longer for me. Glib has internal tests for the main thread and that made things congested. It turned out to be easier for the moment to simply avoid dispatch_main and let glib have the main thread.
Posted by
joconnor
Up vote reply of joconnor Down vote reply of joconnor
Post marked as solved
Add a Comment

Replies

Are you planning to use daemon in a daemon? If so, how is that daemon getting launched?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment
On unix the process parses the command line utils and then based on them it daemonizes so that the command line util can terminate and the daemon hangs around indefinitely.

What I'm doing for macOS is have the command line util parse the params and then XPC them to a mach service registered with launchd.

XPC and dispatch are conflicting with the shared unix glib code for event loops and signal handling. I'm working on making glib use dispatch and dispatch_io with the side benefit of hopefully being more efficient, but I'm wondering if all of this is necessary since the immediate reason to do this is to avoid the daemon call.

Exactly how this will work in the finished product is unknown.
Posted by
joconnor
Up vote reply of joconnor Down vote reply of joconnor
Add a Comment

On unix the process parses the command line utils and then based on them it daemonizes …

But who runs the command-line tool? Do you expect the user to run it with privileges, like using sudo?

If so, that definitely won’t work on macOS. macOS has execution context above and beyond the traditional UNIX uid, gid, and so on, and there’s no good way for a process that starts in a user context to switch to a daemon context. For more background on this, see Technote 2083 Daemons and Agents.

What I'm doing for macOS is have the command line util parse the params and then XPC them to a mach service registered with launchd.

That’s definitely heading in the right direction.

XPC and dispatch are conflicting with the shared unix glib code for event loops and signal handling.

My usual approach for handling this is to run that event loop on a secondary thread and then use the main thread just for XPC. Most event loops like this have some way to route events into the loop from outside, and your XPC code can use that.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Post not yet marked as solved Up vote reply of eskimo Down vote reply of eskimo
Add a Comment
I got things working with dispatch and xpc, so this question isn't really relevant any longer for me. Glib has internal tests for the main thread and that made things congested. It turned out to be easier for the moment to simply avoid dispatch_main and let glib have the main thread.
Posted by
joconnor
Up vote reply of joconnor Down vote reply of joconnor
Post marked as solved
Add a Comment