50

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.

sorin
  • 7,668
  • 24
  • 75
  • 100

3 Answers3

33

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

<key>StandardOutPath</key>
<string>/path/to/logfile.log</string>
<key>StandardErrorPath</key>
<string>/path/to/another_logfile.log</string>

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.

kenorb
  • 5,943
  • 1
  • 44
  • 53
peter
  • 431
  • 4
  • 2
31

I found the solution

 sudo launchctl log level debug

and after this

 tail -f /var/log/system.log
sorin
  • 7,668
  • 24
  • 75
  • 100
  • 1
    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 Nov 15 '10 at 06:06
  • Follow up, FYI: This works with OS X 10.7.2 as well. Thanks. – Alan W. Smith Dec 30 '11 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 Feb 20 '12 at 08:32
  • 32
    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 Oct 22 '14 at 09:48
  • 12
    @JeanMertz - any alternative? – Umang Jan 09 '15 at 08:22
23

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"

chbrown
  • 1,074
  • 10
  • 8