In the last post we talked about how syslog is the central method for logging messages.  It really saves us from having to search all over the system for logs and it also lets the developer log messages without writing their own way of doing it.

Now for the big question, what does syslog do with all those messages?

That’s a good question, we still don’t want to be searching for those messages on our Linux® system.

Looking for the Logs in all the wrong places

Luckily for us, syslog has a configuration file that tells us everything we need to know.  That file is often in /etc/syslog.conf, but depending on your system, it might be somewhere else.  Check the man page for syslogd (that’s the actual program that does the logging) and it will tell you where the file is.  No matter where it’s located, it bas the same purpose.  To tell you where messages are put, based on the priority or the facility.

We know what the priority is, we saw that last time.  What’s the facility?  That’s the purpose of the program making the log message.  For example, if e-mail is logging, then the facility is mail.  If the Linux® kernel is logging, then the facility is kernel.

We know that emerg messages are ‘OH NO THE SYSTEM IS GOING DOWN’, so we probably want to see those on the screen, not shoved away to a log file.    The configuration that does that looks like:

*.emerg							/dev/console

What about mail messages?  Those we would like to put in a file.  It ‘s standard on most Linux® systems to put log messages in /var/log/.  So we’ll put all our messages from the mail system in one place.

mail.*                      /var/log/mail

You can get really complex with the configurations, you want to put mail.debug in one place, mail.alert somewhere else, then you can also put duplicates of everything in a third.  Or you can just stick them all in one place.  The person running the system usually decides this and often the decision is made to leave the defaults alone.  What are the defaults?  Those are the configurations that the system has when everything is first installed.

I bet every time Iron Man does something in his suit, Jarvis makes a note of it.  ‘Shot a Chitauri out of the ski’, ‘did a flip’, ‘took Pepper on a flight’.  That way if something goes wrong, there’s a record of it.  In the computing world, this is called logging.

Making a note every time a computer does something interesting is a good thing.  If something breaks, you have notes that will hopefully let you figure out what happened.  If every program on your computer logged differently, that would be a nightmare, especially if they all put their logs in different places.  Troubleshooting would not be fun.

Instead, Linux® has a program that will do the logging for you.  You just tell syslog what you want to log and how important it is.  Then the syslog daemon will take care of everything for you.   The importance of a message, also known as the priority, has several defined meanings.

From the syslog man page, we can see the list:

• LOG_EMERG system is unusable
• LOG_ALERT action must be taken immediately
• LOG_CRIT critical conditions
• LOG_ERR error conditions
• LOG_WARNING warning conditions
• LOG_NOTICE normal, but significant, condition
• LOG_INFO informational message
• LOG_DEBUG debug-level message

A message logged with the level LOG_EMERG means ‘Danger!  Eek!  Fix me now!’ or ‘It’s too late, we’re going down Iron Man!’.  It can happen when the hard drive decides to fail dramatically.  The syslog can scream ‘Dead Hard drive ahead!’ then fall over dead.

That’s not exactly what happens, but it sounds fun!  My computer yelling ‘Dead Hard drive ahead!’ would certainly get my attention.

On the other end of the list is the LOG_DEBUG message.  Debug messages are usually used by developers, that is, the people who make the programs that run on your system.  The developers use them to debug, that is, find the bugs in their code.  These aren’t literal bugs, of course, but rather things that are unexpectedly happening that shouldn’t be.

Actual bug not found in computer

Next time we’ll talk more about logging and syslog.