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 com.apple.syslogd.plist, 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/com.apple.syslogd.plist ~/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/com.apple.syslogd.plist /System/Library/LaunchDaemons/</code>
Next, we proceed to edit the plist:
<code>sudo nano /System/Library/LaunchDaemons/com.apple.syslogd.plist</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:
<code><string>/usr/sbin/syslogd</string></code>
…and add the following directly below it:
<code><string>-u</string></code>
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/com.apple.syslogd.plist sudo launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist</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/com.apple.syslogd.plist sleep 1 launchctl load /System/Library/LaunchDaemons/com.apple.syslogd.plist</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.
