How do I activate launchd logging on OS X 10.6?

I added a new daemon that is not starting properly (status is 1).

I want to debug the problem but I was not able to find launchd logs, they are not in /var/log/launchd.log.

3 Answers 3


Assuming you're trying to log your process rather than launchd itself, if you include the following lines in the launchd plist file:


and reload the process, any logging or printing that you have internal to your script will be captured in one of those two files whenever it is run. though rotating the files appears to be up to you. as you might expect, if you use the same file in both instances, it will log both error and stdout to the same place.

See: Debugging launchd Jobs section at Creating Launch Daemons and Agents.

  • Thanks! This works for me in Monterey.
    – Vadim
    Commented Jan 9, 2022 at 15:36

I found the solution

 sudo launchctl log level debug 

and after this

 tail -f /var/log/system.log
  • 2
    I've realized that this OS needs admin, just like anything else. Was totally looking for this after a day of screaming "WTF where is the verbose flag!" OSX rocks, sure, but tricky to get a handle on. Thx +1
    – chiggsy
    Commented Nov 15, 2010 at 6:06
  • Follow up, FYI: This works with OS X 10.7.2 as well. Thanks. Commented Dec 30, 2011 at 23:11
  • I've been having issues with my Leopard servers and I thought that there was something wrong with my launchd plist (though the same plist works in Snow Leopard). I happened to stumble onto this and it works like charm :)
    – icasimpan
    Commented Feb 20, 2012 at 8:32
  • 36
    This no longer works since 10.10 Yosemite. launchctl version: Darwin System Bootstrapper 2.0.0: Tue Sep 9 16:30:56 PDT 2014
    – JeanMertz
    Commented Oct 22, 2014 at 9:48
  • 14
    @JeanMertz - any alternative?
    – Umang
    Commented Jan 9, 2015 at 8:22

On OS X 10.11 (El Capitan), you can use sudo launchctl debug <service-target> --stdout --stderr to enable one-off logging, if you don't want to take the filesystem option suggested by @peter.

Lots of stuff is different in the current implementation of launchctl, and the <service-target> is kind of weird. For example, suppose I have a local service that I configure at ~/Library/LaunchAgents/dev.localmon.plist, which has the "label" dev.localmon. Its <service-target> is gui/$UID/dev.localmon, where $UID is your user ID, which, since you're running this at the CLI, your shell will interpolate for you.

So supposing my dev.localmon service was crashing on startup (it was), I could call the following to have launchctl pipe the process's stdout and stderr into my shell the next time (and only the next time) the service starts:

sudo launchctl debug gui/$UID/dev.localmon --stdout --stderr

Since that hangs with the open-and-ready TTYs, go to another terminal and run:

launchctl start dev.localmon
# start is a legacy command and doesn't use the fancy new service-target notation

Then, back in the first terminal, you should see the output. (Oddly, it doesn't close when the service process dies, so you'll have to Ctrl-C.)

Btw, once you fix your config file with whatever PATH or environment was breaking the service before, you still have to use the old launchctl unload ~/Library/LaunchAgents/dev.localmon.plist && launchctl load ~/Library/LaunchAgents/dev.localmon.plist two-step since the documentation's purported uncache subcommand has the following effect:

Command is not yet implemented.

Yay for Apple's post-Jobs release strategy: "Move fast and break things"

  • 1
    sudo launchctl debug exits with Could not find domain for for me
    – Tom
    Commented Jun 11, 2019 at 19:02
  • Thanks! And Jesus MacOs sux
    – sovemp
    Commented Apr 16, 2021 at 22:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .