Articles September 2, 2005 at 1:50 pm

Configuring Tiger’s syslogd to accept logs from external devices

Getting syslogd to be network aware in Tiger

While we have an earlier article on this, it was only for 10.3. So here’s an updated version that will walk you through using syslogd with launchd.Many network devices such as routers, firewalls, and wireless access points, have the ability to send logging messages to other listening devices called syslog servers. Mac OS X uses a syslog server daemon to record its own logging information, and that same daemon can be configured to accept logging information from external devices as well. In this quick tutorial, we’ll do just that by editing a text file and using a new Tiger feature.

Starting with Tiger, syslogd is initiated upon system startup by launchd, a new Apple daemon that manages the instantiation of other daemons and processes. System daemons are launched with the aid of a plist, an XML text file, placed in /System/Library/LaunchDaemons, and a file in that folder, named, is what we must edit to enable external logging functionality.

It’s probably simplest to edit this plist in the Terminal. Backing up this plist file before editing it is a good idea, so start up Terminal and enter this line at the prompt:

<code>sudo cp /System/Library/LaunchDaemons/ ~/Desktop/</code>

For those unfamiliar with the Terminal, this command copies the plist file to the desktop for temporary safekeeping. The command to restore the file back to its original state is inversely thus:

<code>sudo cp ~/Desktop/ /System/Library/LaunchDaemons/</code>

Next, we proceed to edit the plist:

<code>sudo nano /System/Library/LaunchDaemons/</code>

This line starts up the text editor nano as the root user to edit the plist file mentioned above. Scroll down to this line:


…and add the following directly below it:


Save and exit. The -u we’ve inserted is a switch at the end of the syslogd command that tells the process to listen on UDP port 514. Now that syslogd is ready to receive logging messages from other devices, we have to stop the current running syslogd process and restart it with the new option to listen.

<code>sudo launchctl unload /System/Library/LaunchDaemons/

sudo launchctl load /System/Library/LaunchDaemons/</code>

launchctl is a utility that instructs launchd to load and unload daemons, among other things. To verify that syslogd is receiving logging messages from external devices, we can watch the system log in action with this command:

<code>tail -f /var/log/system.log</code>

The last screenful of the syslog will be displayed. When new events are received by syslogd, they’ll be displayed on the screen and written to the log. Control-c will terminate the syslog watch.

That was easy! Well… wait for it… there’s a catch. (You knew that, didn’t you?) As of 10.4.1, there is a bug of some kind that affects syslogd. Each day in the wee hours of the morning, your Mac runs a script called /etc/periodic/daily/500.daily. Near the end of that script, the syslogd process is killed using the old-fashioned Unix kill command and when it restarts, for whatever reason, syslogd simply ceases to function. Not only does it not pay attention to log messages sent from other devices, it doesn’t bother to record logging information from the local machine.

Fortunately, there’s a simple fix. Also near the end of 500.daily, there is a command to call up another file named /etc/daily.local. This file is intended to execute additional commands for specific machines on a daily basis. This file may or may not already exist on your Mac. Either way, let’s edit (or create) it with the following command in the terminal:

<code>sudo nano /etc/daily.local</code>

The contents of this file are pretty simple.

<code>launchctl unload /System/Library/LaunchDaemons/
sleep 1
launchctl load /System/Library/LaunchDaemons/</code>

Save and exit. This script stops and restarts the syslogd process via launchd so that it once again will listen for external logging messages. This script differs just a bit from the commands we used at the terminal. Since 500.daily runs as root and calls up daily.local, daily.local also runs as root, so the sudo command is not needed for launchctl. Also, we’ve inserted a sleep command to give the computer a second to catch its breath.

No Comments

  • I don’t know, I never considered it. Hopefully someone smarter than I will be
    able to respond and help you out.
    My two-bit, half-assed opinion concerning whatever it is I fee like writing about.

  • Arek’s article here has a bit more description on
    how to set up the remote machine to log to a server.

  • Mike Bombich has a fairly new,
    and quiet, site named – On there is exactly one article and while ignoring the apparent spam
    posting, that one article covers splitting the messages that syslogd receives
    by machine (each unique sender) and filing them all away into a defined

    I used this little trick under Panther Server and it worked beautifully. However,
    I’m finding that under Tiger Server, I can’t get it to go. I can get syslogd to
    receive messages remotely and limit what can by ipfw, however his “logsplit”
    script doesn’t seem to work.

    The article is here:

    So, the point of this whole little comment is.. has anyone tried splitting logs
    based on each machine in Tiger Server? That and, while I can confidently
    block what addresses get through via ipfw, does the “-a” option still exist in
    the Tiger version of syslogd?

  • I’ve look at this and it seems to work quite well. However, after 3.15 each day,
    no log file information is being saved at all. After a manual reboot, everything’s
    fine and all log information is being displayed as it’s supposed to. What’s wrong
    with my server? Can anybody help?



  • With regards to the syslogd hang that occurs I’m pretty sure that it’s not
    syslogd that’s broken here. I haven’t quite cracked it yet, but it’s either
    the syslog (no d) command after the syslogd restart, or possibly the log
    rolling of /var/log/mailaccess.log done by /etc/periodic/daily/

    There’s a hash definition near the top of the 700 script that defines a bunch
    of log files to roll, and the process to kill -HUP once rolled. /var/log/
    mailaccess.log is the first one in the hash, with syslog defined as the process
    to HUP. The process_pid function will return the process ID of syslogd (yes,
    even though it says syslog in the hash – it just effectively greps the output of
    ps axwww for syslog so syslogd matches too) and the roll function will kill –
    HUP that process ID. This shouldn’t be causing the problem, but if it’s not the
    syslog command in 500.daily then it has to be this.

    I’m pretty sure from experimentation so far that it’s the syslog command in
    500.daily that’s causing the problem.
    I’ll know for sure in about another hour (it’s 2:15 here now 🙂 ) and post the
    results of my fiddling later today.


  • If I’m configuring syslogd from scratch to log everything from my router, aside
    from pointing my router to my boxses ip address for the syslog server, is there
    anything else I need to do?

    I following these instructions for Tiger and nothing is being logged from my
    router. I’m stumped??

  • I tried it on 10.4.8 and get an awsome message in the system log:
    launchd: execve(): no such file or directory

    I followed the instructions to the letter – albeit I was logged in as root and had
    the developer-tools installed, to make editting .plist files easier.
    It doesn’t matter starting things manually – same error-message.

    I would love to see an example from something that works – and an example
    line that shows how to capture stuff from one single network as well.
    The man page does contain some stuff – but it’s as cryptic as a manpage
    usually gets.

    Anyone? Please?

  • Note that /etc/weekly.local and /etc/monthly.local may need to be created (or amended) too, as the periodic weekly and monthly scripts HUP the syslogd process too.

Leave a reply

You must be logged in to post a comment.