System logging is a very important aspect of maintaining a system and monitoring it for issues. Making logs, implementing your items to log and checking those logs can help you keep systems running smoothly.
In this article we will look at the following commands:
Other commands may be used to show the logs; or more specifically, portions of the logs.
The ‘lastlog’ program is used to show the last time a user logged into the system. The log file is located at ‘/var/log/lastlog’.
NOTE: The ‘lastlog’ command works well on CentOS, but on Ubuntu, you may need to use the command ‘last’. On Ubuntu, the GDM will not register the login information when logging into the GUI. You can use the ‘last’ command to accomplish the same thing as ‘lastlog’.
You most likely will get a listing of a lot of accounts that have ‘Never logged in’. Figure 1 shows a screenshot of the ‘lastlog’ command in CentOS. The same command is shown in Figure 2 for Ubuntu.
Be aware that to get the accounts to not show ‘Never logged in’ on Ubuntu I had to log into TTY2 and not just the GUI. From the GUI I also used the ‘login’ command in a Terminal to force the user’s login to be updated in the database.
For Ubuntu, you get a better listing of the last logged in information from the command ‘last’. The ‘last’ command will show the TTY into which a user logged into the system. It also shows the kernel version used by the user. The date and time are given for each login. An entry is also made for when a shutdown or reboot occurs. An example of the ‘last’ command is shown in Figure 3. The information from which the ‘last’ command gets data comes from ‘/var/log/wtmp’.
The ‘last’ command also works in CentOS.
When using the ‘last’ command you can use the command ‘last reboot’ to see the listing of when the system was booted. If you want to see when a specific user logged into the system, you can use the command ‘last username‘. For example, on my system, I would use the command ‘last jarret’ to see when I logged in last.
If log files are continuously used with new entries being added daily, the files would get quite large. Depending on your file system, you could end up making the file too large to be supported. For example, if you were to use FAT32 to format your hard drive, you could only have log files up to 4 GB in size.
The logs are rotated once a day by default. The script is found at ‘/etc/cron.daily/logrotate’ and is as follows:
# Clean non existent log file entries from status file
test -e status || touch status
head -1 status > status.clean
sed ‘s/”//g’ status | while read logfile date
[ -e “$logfile” ] && echo “”$logfile” $date”
done >> status.clean
mv status.clean status
test -x /usr/sbin/logrotate || exit 0
To see the script working, you can run ‘logrotate -d /etc/logrotate.conf’. The parameter ‘-d’ will perform a test. The screen output will show what could/should be performed, but nothing is changed. The second parameter ‘/etc/logrotate.conf’ specifies the location and name of the configuration file to use for the test.
NOTE: If you want to perform a log rotation, then remove the ‘-d’ option.
Now, let’s look at the configuration file ‘logrotate.conf’:
# see “man logrotate” for details
# rotate log files weekly
# use the syslog group by default, since this is the owning group
# of /var/log/syslog.
su root syslog
# keep 4 weeks worth of backlogs
# create new (empty) log files after rotating old ones
# uncomment this if you want your log files compressed
# packages drop log rotation information into this directory
# no packages own wtmp, or btmp — we’ll rotate them here
create 0664 root utmp
create 0660 root utmp
# system-specific logs may be configured here
We can see the configuration information specifies that the log rotations are performed weekly. Log files are kept for four weeks. A new empty file is created when the logs are rotated. The log files are not compressed when backed up. Log information is kept in ‘/etc/logrotate.d’. Finally, two logs are backed up – ‘wtmp’ and ‘btmp’. The two backed up log files have a different rotation plan than the default.
Create a Rule
Sometimes, the default logging is not what you need. You may need more information to be logged.
You can log information for specific services, or priorities, for the system itself. The priorities are as follows:
- auth/authprivate: security/authorization messages
- cron: cron messages
- daemon: system daemons
- kern: kernel messages
- local0-local7: local use messages
- lpr: line printer messages
- mail: mail system messages
- news: USENET News system messages
- syslog: system log daemon messages
- user: user level messages
- uucp: user and group subsystem messages
The other part you need to determine is the amount of logging. The amount of logging, or the priority, is as follows:
- debug: Debug information
- info: Informational message
- notice: Condition that might require intervention
- warn: Warning errors
- err: Error condition
- crit: Critical error
- alert: Condition that needs immediate attention
- emerg: Emergency is
If we wanted to create logging for the system, we could use the ‘local#’ facility (where # is 0-7). We then need to know which priority to use for logging. When you pick a priority, logging will occur on all other priorities below it in the list. If you chose ‘info’, it would also log ‘info’, ‘notice’, ‘warn’, ‘err’, ‘crit’, ‘alert’ and ‘emerg’. So the logging would be labeled as ‘local0.crit’. If you would want to only log ‘info’ and nothing below it in the list, the priority would be ‘local0.=info’.
To enable the logging you need to edit the file ‘/etc/rsyslog.conf’ For the last line you need to add the following line:
The second parameter is the location of the log file used for the specific entry, which can be any valid file name you want to use. After saving the file you will need to restart the ‘rsyslog’ service to include the new logging entry. To restart the service, use the command:
systemctl restart rsyslog
If you wanted to test the logging you can force a message to the log file by issuing the command:
logger -p local0.info “Information message issued by me!”
logger -p local0.warn “Warning message!”
NOTE: You can specify the priority of the error message after the period (.).
Now, you can list the contents of the log file with the command:
Now that we have created logs and know the placement of the logs, it is beneficial to be able to easily read them.
The command ‘journalctl’ will combine all of the logs located at ‘/var/log/*’ into one listing on the screen. Displaying the content on the screen is the default. It is also default that the list is a complete list, oldest entries first, with all of the log entries sorted by date and time.
NOTE: If you include your own special log, as discussed above, the contents are included in the listing.
The listing is made using the ‘less’ command. You can use the ‘Page Up’ and ‘Page Down’ key to move around. Use the left and right arrow keys to see lines that go off the screen. Use ‘Home’ and ‘End’ keys to move to the beginning and end of the listing. To exit the listing, press ‘CTRL+C’.
If you only want to see the last 10 entries of the file, the most recent ten entries, you use the command ‘journalctl -n’. If you want more entries listed then you include the number of entries you desire to see. If you wanted to see 20 entries the command would be ‘journalctl -n 20’
Since all services are included in the listing it is possible to see only entries from a specific service. If you only wanted to see all of the ‘cron’ service entries, the command is ‘journalctl -u cron’. The listing may quite a long one and you can include the ‘-n’ just to see the most current ten entries for ‘cron’.
Look into the man page for ‘journalctl’ to see more available options. Practice all of these commands, as well as their other parameters, to make sure you understand their capabilities.