Next week: Apple System Logger

2008-01-19 12:00:00 UTC

In Mac OS X 10.4, Apple introduced a new logging system called Apple System Logger. ASL is comprised of three parts:

  • A logging API with all the capabilities of syslog(3) and more. You may think of it as the Quartz or QuickDraw GX to syslog’s QuickDraw.
  • syslogd. Apple’s implementation is modular; on Mac OS X, it includes (among many other modules, well-documented in Mac OS X Internals) an input for communication with ASL clients (i.e., your app) and an output that reads and writes the ASL database. (Minor note: Tiger uses a log file instead of a database.)
  • A front-end command-line tool, confusingly named syslog(1), even though it uses the ASL API rather than syslog(3).

The implementations of all three parts are open-source. The logging API is part of Libc, and syslogd and the command-line utility are the two halves of the syslog project. (In case you’re wondering: Those exist in Tiger’s Libc and Tiger’s syslog as well.)

The API is declared with plenty of comments in /usr/include/asl.h, and documented* in a manpage, though neither of those is exactly an exhaustive treatment of the API.

So, over the next Beatles’ week, I’m going to run a series of posts about ASL. I plan to give you:

  • A tutorial on using the ASL API
  • Bits of code and suggestions that go beyond the documentation
  • Three of my test apps, which are general enough that someone should be able to use them for purposes other than simply pounding on the API

Stay tuned!

(Also, this is post #601 in WordPress’ DB. Woo!)

Posts in this series


* While I was in Cupertino, I told Blake that it’s undocumented, but after I got home, I found the manpage. It exists in both Tiger and Leopard. Oops. Sorry, Blake.

9 Responses to “Next week: Apple System Logger”

  1. ssp Says:

    An interesting question to have answered would be what the advantages of this system are. In theory it may be all great and fancy. But my impression so far, particularly for replacing system.log is that it’s much less reliable, keen on losing entries and keeping less of a backlog. And with not being a simple text file, having a decent UI for it (search by date!) seems important as well. If some process runs mad and writes thousand of messages to the log, for example, it’s quite a hassle to get a view at older items.

    I guess I want to say that an ASL viewer that’s far better than Console.app would be much better than mere programming examples ;)

  2. Peter Hosey Says:

    ssp: syslogd enforces a size limit on the ASL database. If it grows past 25,600,000 bytes, syslogd prunes the oldest messages. You can raise (or lower) the size limit by adding a -db_max argument to syslogd’s arguments in its launchd plist.

    As for decent UIs for searching the logs… stay tuned. ☺

  3. Jeff Johnson Says:

    ssp: I guess I want to say that an ASL viewer that’s far better than Console.app would be much better than mere programming examples ;)
    https://bugreport.apple.com/

  4. Peter Hosey Says:

    Console isn’t bad. It could be better, but it does offer more power than is obvious at first glance.

    I won’t say more now, though, because I don’t want to give away spoilers. ☺

  5. Blake C. Says:

    No worries about the man page, Peter- no harm, no foul :) I have no experience with asl and I can’t wait to see what you have for us…

  6. ssp Says:

    Peter: Looking forward to all that. (I’m not too happy with manipulating launchd files which I may find overwritten by some update. Is there a way to achieve the same through defaults?)

    Curious about those non-obvious Console options. I’d be surprised if you managed to find sane and fast temporal navigation somewhere in there.

    Jeff: filed those issues long ago.

  7. Jeff Johnson Says:

    ssp: I wrote my comment before I saw Peter’s. I thought it was unfair to ask him to do Apple’s job, but it turns out he may have done it anyway! (Hard to tell from the teaser, though.)

  8. ssp Says:

    I’m afraid this didn’t help me too much. I mostly don’t care about logs in such an extent that I’d see a big benefit in this infrastructure, so in the end it seems to be for the pleasure of the OS or something.

    Practical questions I’d have for log files would be: How can I get the information I want quickly and without much effort. I guess the architecture could actually deliver on that, but I am missing the single button click way to get all log messages of a process that just crashed and any other potentially related log messages around it.

    Even more painfully, I find that the whole logging architecture just seems overly complicated. What should I do when the syslogd process starts running amok and when killing it just respawns it to a new amok run. What should I do then? Pausing the syslogd process doesn’t seem a good idea as Apple’s clever libraries seem to ensure that some applications just stall as a consequence. From what I can tell only a restart might solve the problem. Which is much more of a downside to this overly ‘clever’ bit of engineering than all the upsides you mention present. After all I mainly want to actually _use_ my computer to do things rather than to have it store logs in a clever way.

    I’m sure there are environments where clever logging is essential. Servers or something perhaps. But on my own system I have other priorities – and, even after reading the manuals and your extra explanations, remain less than impressed.

  9. Peter Hosey Says:

    Practical questions I’d have for log files would be: How can I get the information I want quickly and without much effort. I guess the architecture could actually deliver on that, but I am missing the single button click way to get all log messages of a process that just crashed and any other potentially related log messages around it.

    The API is more general than that. There isn’t a single easy function for every possible use of the API, just as there isn’t in any other Apple API; you build your use of it from its component functions—in this case, a couple calls to asl_search, and a loop that calls the aslresponse functions.

    It wouldn’t be hard to write a function that:

    • creates a query for ASL_KEY_SENDER == process_name
    • searches for it
    • calls a function on every message from the response
    • creates a query for ASL_KEY_MSG contains process_name
    • searches for it
    • calls a function on every message from the response

    What should I do when the syslogd process starts running amok and when killing it just respawns it to a new amok run. What should I do then?

    That’s a sysadmin problem. This series was primarily about the API, with information about the daemon provided as context for parts of the API (e.g., ASL_OPT_NO_DELAY).

    To answer your question: Try using launchctl to disable it.

Leave a Reply

Do not delete the second sentence.