In this lesson, you will learn why you may want to use logging in your shell scripts. You'll also learn about the syslog standard and how to generate messages that conform to that standard. Finally, you'll learn how to create your own custom logging functions. 

If you want to keep a record of what occurred during an execution of a shell script, you'll want to employ some sort of logging mechanism. Logs can store any type of information you want but they typically answer who, what, when, where, and why something occurred. Logs can be useful when your shell script performs several actions or produces a lot of output that might scroll off your screen. Also, if you plan to run your shell script unattended via cron or some other means, you might want a way to look back and see exactly what happened and when it happened during a previous run. The Linux operating system uses the syslog standard for message logging. This allows programs and applications to generate messages that can be captured, processed, and stored by the system logger. It eliminates the need for each and every application having to implement a logging mechanism. This means that we can take advantage of this logging system in our shell scripts. 

Before we start using it, let's briefly talk about how it works. The syslog standard uses facilities and severities to categorize messages. Each message is labeled with a facility code and a severity level. The various combinations of facilities and severities can be used to determine how a message is handled. Facilities are used to indicate what type of program or what part of the system the message originated from. For example, messages that are labeled with a kern facility originate from the Linux kernel. Messages that are labeled with a mail facility, come from applications involved in handling mail. There are several facilities. If your script is involved in handling mail, you could use the mail facility for logging. If it's not clear what facility to use you can simply use the user facility. Also, the facilities ranging from local0 to local7 are to be used to create custom logs. These facilities would also be appropriate for custom written shell scripts. The severities are emergency, alert, critical, error, warning, notice, info, and debug. The most severe message is an emergency message. And the least severe message is a debugging message. These combinations of facilities and severities are used by the system logger to handle these messages. Most messages are simply written to a file. Each distribution uses a slightly different set of defaults and these logging rules are configurable and can be changed. You'll find many messages stored in /var/log/messages on some distributions, while others use /var/log/syslog, for example. You'll have to consult the documentation for the system logger that is in use on your system. It's typically one of syslogd, rsyslog, or syslog-ng, although there are several other possibilities. Okay, now that you know about the standard logging system that is in play, you can take advantage of this in your shell scripts by using the logger command. The logger command generates syslog messages. In its simplest form. you simply supply a message to the logger utility. By default, the logger utility creates messages using the user facility and the notice severity. If you want to specify the facility and severity, you use the -p option followed by the facility, then a period, and then the severity. So to use local0 facility and the info severity, you would run logger space -p local.info, and then follow that with the message you want to generate. If you want to tag your message, use the -t option. Typically you'll want to use the name of your script as the tag. This way you can search for the name of your script in a log file to extract just the messages for your script. If you want to include the PID, or process ID, in the log message use the -i option. 

Let's look at the messages generated by these logger commands. The first logger command is used without any options. You can see that it generates a message with a timestamp and includes the message passed to the logger command. This message will be routed based on the system logger configuration. For most distributions, this message will end up in the /var/log/messages file or the /var/log/syslog file. The next logger command generates the same message, but this time we have specified the facility and severity. Remember that different facilities and severities can cause the system logger to route the messages to a different log file. 

If you want to display the message to the screen, in addition to sending it to the logging system, use the -s option. The first logger command on your screen uses a tag. The message that it generates now contains the specified tag. The other logging command uses the -i option which causes the PID to be included in brackets in the log message. If multiple copies of your script can run at the same time, then having a PID can help differentiate the logs being generated by one instance of a script versus logs being generated by another instance of the script. You can even create a function in your shell script to handle logging. Here's an example from one of my scripts. This function named logit expects that a log level be passed into it, followed by a message. It assigns the first thing passed into it to the LOG_LEVEL variable. Next shift is run to shift the positional parameters to the left. This means that the special variable DOLLAR@ contains everything but the first positional parameter which we already used for our LOG_LEVEL variable. Everything that is left over is assigned to the MSG variable. Next a TIMESTAMP variable is created and assigned some output from the date command. If the LOG_LEVEL variable is set to ERROR or the VERBOSE global variable is set to true, then a message is echoed to the screen which includes information such as the timestamp, the log level, and of course the message. Instead of using echo this function could have employed the use of the logger command if we wanted to do that. 

Here's some examples of calling this function. The first time it's called, the INFO log level is used and the message is Processing data. If the command fetch-data $HOST fails, then the logit function is called with an ERROR log level and a message that states, "Could not fetch data from $HOST." The fetch-data command in this example is made up. It could be another shell script, for example. but in any case, this gives you an idea of how you can use a custom written logging function. 

In this lesson you learned why you may want to use logging in your shell scripts. You also learned about the syslog standard and how to generate messages with a logger utility that take advantage of this standard. Finally, you learned how to create and use your very own custom logging functions.