1

Are there any drawbacks of building a background-only COCOA app without any GUI and run it as a launch daemon. This would use: 

import <Foundation/Foundation.h>
import <AppKit/AppKit.h>
import <CoreData/CoreData.h>

The primary advantage of using this and not building a objective-C command line tool is that It offers an implicit run-loop with benefits including well defined callbacks when application finishes launch or during termination. This would need to be explicitly implemented in a command line app.

Are there any disadvantages such as functionality break? Will the launch of the daemon be deferred?

ZestyZest
  • 911
  • 13
  • 27
  • If it's background-only then why do you need Cocoa? – trojanfoe Apr 29 '15 at 07:25
  • because I am using NSApplicationDelegate which relies on AppKit – ZestyZest Apr 29 '15 at 07:31
  • You don't need that. I wrote [RunLoopController](https://github.com/trojanfoe/RunLoopController) which allows you do use Objective-C/Foundation in a command line utility (which could easily be modified to a daemon). – trojanfoe Apr 29 '15 at 07:38
  • ok, but is there any disadvantage of using NSApplicationDelegate and Cocoa framework for launchdaemon as it makes things pretty streamlined and straightforward. This was the primary question. – ZestyZest Apr 29 '15 at 08:02
  • Well you are using a tiny piece of a very large framework. If you want to use Foundation classes then you need a runloop (and that's where RunLoopController comes in) and any other facility of `NSApplicationDelegate` can be easily replaced with your own code (see some of the examples bundled with RunLoopController for deciding when to terminate, for example). – trojanfoe Apr 29 '15 at 08:04
  • What exactly do you mean by a "launch daemon"? Do you mean a [daemon](https://developer.apple.com/library/mac/technotes/tn2083/_index.html#//apple_ref/doc/uid/DTS10003794-CH1-SUBSECTION2) which runs outside of a user login context? Or do you mean an [agent](https://developer.apple.com/library/mac/technotes/tn2083/_index.html#//apple_ref/doc/uid/DTS10003794-CH1-SUBSECTION3), which runs within a user login context? – Ken Thomases Apr 29 '15 at 08:49
  • @Ken, I mean a daemon that runs in root context. – ZestyZest Apr 29 '15 at 09:20
  • @Trojanfoe, I'll give a try. Out of curiosity, Even if we use AppKit in a launch daemon, how adversely would it affect the functionality of the program – ZestyZest Apr 29 '15 at 09:22
  • @Anil Probably nothing at all; you'd have to try. However it is possible it will attempt to connect to the window server as using it implies the use of the screen. I am not certain. – trojanfoe Apr 29 '15 at 09:23

1 Answers1

3

For a daemon, there are serious drawbacks to using any non-daemon-safe framework. From Technical Note TN2083: Daemons and Agents – Layered Frameworks:

Layered Frameworks

Most Mac OS X functionality is implemented by large system frameworks. Many of these frameworks use Mach-based services that they look up using the bootstrap service. This can cause all sorts of problems if you call them from a program which references the wrong bootstrap namespace.

Apple's solution to this problem is layering: we divide our frameworks into layers, and decide, for each layer, whether that layer supports operations in the global bootstrap namespace. The basic rule is that everything in CoreServices and below (including System, IOKit, System Configuration, Foundation) should work in any bootstrap namespace (these are daemon-safe frameworks), whereas everything above CoreServices (including ApplicationServices, Carbon, and AppKit) requires a GUI per-session bootstrap namespace. …

In summary, the concrete recommendations are:

  • When writing a daemon, only link to daemon-safe frameworks (see Framework Cross Reference).

  • When writing a GUI agent, you can link with any framework.

  • If you're writing a daemon and you must link with a framework that's not daemon-safe, consider splitting your code into a daemon component and an agent component. If that's not possible, be aware of the potential issues associated with linking a daemon to unsafe frameworks (as described in the next section).

Living Dangerously

If your daemon uses frameworks that aren't daemon-safe, you can run into a variety of problems.

  • Some frameworks fail at load time. That is, the framework has an initialization routine that assumes it's running in a per-session context and fails if it's not.

    This problem is rare on current systems because most frameworks are initialized lazily.

  • If the framework doesn't fail at load time, you may still encounter problems as you call various routines from that framework.

    • A routine might fail benignly. For example, the routine might fail silently, or print a message to stderr, or perhaps return a meaningful error code.

    • A routine might fail hostilely. For example, it's quite common for the GUI frameworks to call abort if they're run by a daemon!

    • A routine might work even though its framework is not officially daemon-safe.

    • A routine might behave differently depending on its input parameters. For example, an image decompression routine might work for some types of images and fail for others.

  • The behavior of any given framework, and the routines within that framework, can change from release-to-release.

The upshot of this is that, if your daemon links with a framework that's not daemon-safe, you can't predict how it will behave in general. It might work on your machine, but fail on some other user's machine, or fail on a future system release, or fail for different input data. You are living dangerously!

Read the whole technote for the full details.

Ken Thomases
  • 88,520
  • 7
  • 116
  • 154
  • Thanks for the explanation. Could you please point to the documentation that list the frameworks which are daemon safe? Where is this:(see Framework Cross Reference)? – ZestyZest Apr 29 '15 at 09:39
  • It immediately follows the part of the document I linked to and quoted, but I'll edit with a link. – Ken Thomases Apr 29 '15 at 09:40