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.
by 
I don’t know, I never considered it. Hopefully someone smarter than I will be
able to respond and help you out.
—
http://www.aaronadams.net
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 dittomac.com – 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
directory.
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: http://www.dittomac.com/index.php?topic=mosxs.
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?
Cheers,
Chris
Yea, I had the same problem and posted the solution a week ago. Search on Tiger syslogd or see:
https://www.afp548.com/forum/viewtopic.php?forum=4&showtopic=10127#10127
russ
So if the logging stopped after the purge command in the nightly /etc/periodic/daily script has run, how do we fix it?
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/
700.daily.server.cyrus
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.
Woz
/etc/syslog.conf will let you separate things out. More info in the man page.
—
Changing the world, one server at a time.
Joel Rennich
http://www.afp548.com
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: com.apple.syslogd: 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.