Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the recommended way for packaging a C++ daemon on Mac OSX?

I'm working on a multi-platform project that is composed of a service/daemon which runs on Windows, Linux, and Mac OSX.

The code I have is portable, and the application runs fine (from the command line) on all the systems. As this application is designed to run in the background, I made it a Windows service on Windows and a Linux daemon (with the appropriate scripts in init.d) for Linux.

Now my problem is Mac OSX: I have little experience with this operating system, and I am having hard times figuring out the best practices for it regarding my situation:

I'd like to have an installer for my project (I believe a .dmg file, that would likely install an .app; please correct me if there is a better alternative).

Here some information about this project of mine:

  • It is build entirely in C++ (it uses boost, curl, iconv)
  • The current build system is not XCode (however If there is a way of keeping my current code layout while integrating and building everything into XCode, I don't mind. I've done something similar for Windows anyway).
  • There is no graphical user interface
  • The daemon should start on startup automatically (or even better: make that a user's choice).
  • The daemon requires root access during its execution.

That's probably a lot of context to consider for a single question, so I will try to make it easier to read:

How would you package/create an installer for a pure-C++ daemon on Mac OSX ?

like image 344
ereOn Avatar asked Nov 08 '13 14:11

ereOn


1 Answers

Since this doesn't have a UI, I wouldn't package it as a .app -- that's the preferred format for double-clickable GUI apps, not for daemons. If it's just a single binary (no support files except maybe things like config files, etc), I'd follow unix conventions and put the binary someplace like /usr/local/libexec (or wherever you put it on Linux). Note that /usr/local doesn't exist by default on OS X, so your installer will need to create it if it doesn't exist.

For getting it to execute: I'll agree with James Bedford's suggestion of using launchd. The launchd .plist file should be installed in /Library/LaunchDaemons (LaunchDaemons run as root at startup, while LaunchAgents run as normal users when that user logs in). Make sure the daemon does not drop itself into the background -- launchd keeps watch over the programs it launches, and if they background themselves it thinks they've crashed, and generally tries to relaunch them, which doesn't work very well. You can adjust the settings to work with background programs, but it's best to have it run in the foreground.

For packaging: Here, I agree with mah -- use an installer package. I actually still like the old GUI PackageMaker tool (deprecated, but it still works), but the new CLI tools are probably better to learn at this point. If you follow my recommendation about /usr/local/libexec, your package should actually contain the "local" directory (with libexec subdir and your binary in that), and install that into /usr -- if /usr/local already exists, it'll just merge with what's already there, but if not it'll create the entire thing. On the other hand, /Library/LaunchDaemons is guaranteed to exist, so your package only needs to contain the actual .plist file to put in it.

like image 51
Gordon Davisson Avatar answered Jan 03 '23 15:01

Gordon Davisson