Ubuntu log file. Real-time Linux log tracking. General Log Files

As you know, Linux has a very important tool sysklogd, which allows you to keep a log of events occurring in the system. System administrators, and indeed any user who encounters errors, will have to look linux logs to identify the problem and solve it.

All linux log files are located in the folder:
/var/log

Linux log files:
messages Contains global Linux system logs, including those logged at system startup.
dmesg Contains messages received from the kernel. Logs many messages during the boot phase, they display information about hardware devices that are initialized during the boot process. The number of messages in the log is limited, and when the file is full, with each new message the old ones will be overwritten.
auth.log Contains information about user authorization in the system, including user logins and authentication mechanisms that were used.
boot.log Contains information that is logged when the system boots.
daemon.log Includes messages from various background daemons
kern.log Also contains messages from the kernel, useful in troubleshooting errors in custom modules built into the kernel.
lastlog Displays information about the last session of all users. This is a non-text file and you must use the lastlog command to view it.
mail.log server logs Email running on the system.
user.log Information from all logs at the user level.
Xorg.x.log X server message log.
btmp Contains information about failed login attempts.
cups All messages related to printing and printers.
cron Whenever the Cron daemon starts executing a program, it writes a report and messages from the program itself in this file.
secure Contains information related to authentication and authorization.
wtmp Contains a log of user logins. Use the wtmp command to display the contents of this file.
faillog Contains failed login attempts. Use the faillog command to display the contents of this file.
mysqld.log Contains MySQL database server log files.

You can view Linux logs using several console programs. Below we will look at a few examples:

1. Outputting and scrolling through text using less:
less /var/log/messages

2. View logs in real time:
tail -f /var/log/messages

3. Open the file using cat:
cat /var/log/dmesg

4. Output the first 10 lines from the file:
head /var/log/dmesg

5. Output the last 10 lines from the file:
tail /var/log/dmesg

6. Output a certain number of lines:
head -n3 /var/log/dmesg
where -n3 is the number of lines to be shown.

7. We display only errors:
grep -i error /var/log/messages

In addition to the console and text editors, you can also use graphics program“System Log Viewer”, which will show you in a convenient and visual form Linux logs.

System administrators, and ordinary ones Linux users, should often look at log files to troubleshoot problems. In fact, this is the first thing any system administrator should do when any error occurs in the system.

The Linux operating system itself and the running applications generate Various types messages that are logged in various log files. Linux uses a special software, files and directories for storing log files. Knowing which files contain the logs of which programs will help you save time and solve the problem faster.

In this article we will look at the main parts of the Linux logging system, log files, as well as utilities with which you can view Linux logs.

Most Linux log files are located in the /var/log/ folder. You can list the log files for your system using the ls command:

Rw-r--r-- 1 root root 52198 May 10 11:03 alternatives.log
drwxr-x--- 2 root root 4096 Nov 14 15:07 apache2
drwxr-xr-x 2 root root 4096 Apr 25 12:31 apparmor
drwx------ 2 root root 4096 May 5 10:15 audit
-rw-r--r-- 1 root root 33100 May 10 10:33 boot.log

Below we will look at 20 different Linux log files located in the /var/log/ directory. Some of these logs are only found on certain distributions, for example dpkg.log is only found on Debian based systems.

/var/log/messages- contains global Linux system logs, including those that are recorded at system startup. Several types of messages are recorded in this log: mail, cron, various services, kernel, authentication and others.

/var/log/dmesg- contains messages received from the kernel. Logs many messages during the boot phase, they display information about hardware devices that are initialized during the boot process. You can say this is another log of the Linux system. The number of messages in the log is limited, and when the file is full, with each new message the old ones will be overwritten. You can also view messages from this log using the dmseg command.

/var/log/auth.log- contains information about user authorization in the system, including user logins and authentication mechanisms that were used.

/var/log/boot.log- Contains information that is logged when the system boots.

/var/log/daemon.log- Includes messages from various background daemons

/var/log/kern.log- Also contains messages from the kernel, useful in troubleshooting errors in custom modules built into the kernel.

/var/log/lastlog- Displays information about the last session of all users. This is a non-text file and you must use the lastlog command to view it.

/var/log/maillog /var/log/mail.log- logs of the email server running on the system.

/var/log/user.log- Information from all logs at the user level.

/var/log/Xorg.x.log- X server message log.

/var/log/alternatives.log- Information about the operation of the update-alternatives program. These are symbolic links to default commands or libraries.

/var/log/btmp- Linux log file contains information about failed login attempts. To view the file, it is convenient to use the command last -f /var/log/btmp

/var/log/cups- All messages related to printing and printers.

/var/log/anaconda.log- all messages recorded during installation are saved in this file

/var/log/yum.log- Logs all information about package installations using Yum.

/var/log/cron- Whenever the Cron daemon starts executing a program, it writes a report and messages from the program itself in this file.

/var/log/secure- contains information related to authentication and authorization. For example, SSHd logs everything here, including failed login attempts.

/var/log/wtmp or /var/log/utmp - Linux system logs , contain a log of user logins. Using the wtmp command you can find out who is logged in and when.

/var/log/faillog- log linux systems, contains failed login attempts. Use the faillog command to display the contents of this file.

/var/log/mysqld.log- Linux log files from the MySQL database server.

/var/log/httpd/ or /var/log/apache2- log files linux11 web Apache server. Access logs are in the access_log file, and error logs are in the error_log

/var/log/lighttpd/- Linux logs of the lighttpd web server

/var/log/conman/- ConMan client log files,

/var/log/mail/- this directory contains additional mail server logs

/var/log/prelink/- Prelink program links libraries and executable files to speed up the download process. /var/log/prelink/prelink.log contains information about .so files that were modified by the program.

/var/log/audit/- Contains information generated by the auditd daemon.

/var/log/setroubleshoot/ - SE Linux uses the setroubleshootd daemon (SE Trouble Shoot Daemon) to report security problems. This log contains messages from this program.

/var/log/samba/- contains information and logs from the Samba file server, which is used to connect to shared Windows folders.

/var/log/sa/- Contains .cap files collected by the Sysstat package.

/var/log/sssd/- Used by the system security daemon that manages remote access to directories and authentication mechanisms.

Viewing logs in Linux

To view logs on Linux it is convenient to use several utilities command line Linux. It can be any text editor, or special utility. Most likely, you will need superuser rights to view logs in Linux. Here are the commands that are most often used for these purposes:

  • zgrep
  • zmore

I will not go into detail on each of these commands, since most of them have already been discussed in detail on our website. But I will give a few examples. Viewing Linux logs is very simple:

We look at the log /var/log/messages, with the ability to scroll:

less /var/log/messages

View Linux logs in real time:

tail -f /var/log/messages

Open the dmesg log file:

cat /var/log/dmesg

First lines of dmesg:

head /var/log/dmesg

We only output errors from /var/log/messages:

grep -i error /var/log/messages

In addition, you can view logs on Linux using graphical utilities. System program Log Viewer can be used to convenient viewing and monitoring system logs on a laptop or personal computer with Linux.

You can install the program on any system with an X server installed. Also, any graphical test editor can be used to view logs.

conclusions

In the /var/log directory you can find all the necessary information about the operation of Linux. From today's article you have learned enough to know where to look and what to look for. Now viewing logs in Linux will not cause you problems. If you have any questions, ask in the comments!



It is impossible to imagine the user and administrator of the server, or even workstation based on Linux, which never read log files. The operating system and running applications constantly generate various types of messages, which are logged in various log files. Ability to determine required file log and what to look for in it will help to significantly save time and quickly resolve the error.

Logging is the main source of information about system operation and errors. This quick guide will cover the basics of logging. operating system, directory structure, programs for reading and reviewing logs.

Basic log files

All log files can be classified into one of the following categories:

  • applications;
  • events;
  • services;
  • systemic.

Most log files are contained in the /var/log directory.

  • /var/log/syslog or /var/log/messages contains a global system log in which messages are written from the moment the system starts, from the Linux kernel, various services, detected devices, network interfaces and much more.
  • /var/log/auth.log or /var/log/secure- information about user authorization, including successful and unsuccessful login attempts, as well as the authentication mechanisms involved.
  • /var/log/dmesg- device drivers. Using the command of the same name, you can view the output of the file contents. The log size is limited, when the file reaches its limit, older messages will be overwritten by newer ones. By setting the --level= switch, you can filter the output by significance criterion.
Supported logging levels (priorities): emerg - system unused alert - action must be performed immediately crit - criticality conditions err - error conditions warn - warning conditions notice - common but significant conditions info - informational debug - debug messages (5:520)$ dmesg -l err usb 1-1.1: 2:1: cannot get freq at ep 0x1 usb 1-1.1: 1:1: cannot get freq at ep 0x81 usb 1-1.1: 1:1: cannot get freq at ep 0x81
  • /var/log/alternatives.log- The output of update-alternatives, which contains symbolic links to the default commands or libraries.
  • /var/log/anaconda.log- Entries recorded during system installation.
  • /var/log/audit- Records generated by the auditd audit service.
  • /var/log/boot.log- Information that is written when the operating system boots.
  • /var/log/cron- Crond service report executable commands and messages from the teams themselves.
  • /var/log/cups- Everything related to printing and printers.
  • /var/log/faillog- Failed login attempts. Very useful when checking security threats, hacker attacks, and brute force hacking attempts. You can read the contents using the faillog command.
  • var/log/kern.log- The log contains messages from the kernel and warnings that can be useful in troubleshooting errors in custom modules built into the kernel.
  • /var/log/maillog/ or /var/log/mail.log- Log of the mail server used on the OS.
  • /var/log/pm-powersave.log- Battery saving service messages.
  • /var/log/samba/- Logs of the Samba file server, which is used to access shared folders Windows and sharing Windows users to Linux shared folders.
  • /var/log/spooler- For the old school, contains USENET messages. Most often it is empty and abandoned.
  • /var/log/Xorg.0.log- X server logs. Most often they are useless, but if they contain lines starting with EE, then you should pay attention to them.

There will be a separate package manager log for each distribution.

  • /var/log/yum.log- For programs installed using Yum on RedHat Linux.
  • /var/log/emerge.log- For ebuilds installed from Portage using emerge on Gentoo Linux.
  • /var/log/dpkg.log- For programs installed using dpkg on Debian Linux and the entire family of related distributions.

And some binary logs of user sessions.

  • /var/log/lastlog- Last user session. You can read it with the last command.
  • /var/log/tallylog- Audit of failed login attempts. Output to the screen using the pam_tally2 utility.
  • /var/log/btmp- One more log of unsuccessful login attempts. Just like that, just in case you haven’t figured out where to look for traces of hacker activity.
  • /var/log/utmp- List of currently logged-in users.
  • /var/log/wtmp- Another log to record user logins. Displayed on screen using the utmpdump command.
(5:535)$ sudo utmpdump /var/log/wtmp [Tue Aug 11 16:50:07 2015] [~~ ] [Tue Aug 11 16:50:08 2015] [~~ ] [Tue Aug 11 16: 50:57 2015] [Tue Aug 11 16:50:57 2015] [~~ ] [Tue Aug 11 16:50:57 2015]

And other magazines

Since an operating system, even one as wonderful as Linux, in itself does not provide any tangible benefits, most likely a database, a web server, and various applications will be running on a server or workstation. Each application or service can have its own event and error log file or directory. Naturally, it is impossible to list all of them, only a few.

  • /var/log/mysql/- MySQL database log.
  • /var/log/httpd/ or /var/log/apache2/- Apache web server log, the access log is in access_log, and errors are in error_log.
  • /var/log/lighthttpd/- Lighttpd web server log.

The user's home directory may contain logs graphic applications, DE.

  • ~/.xsession-errors- Stderr output from X11 graphics applications.
Initializing "kcm_input" : "kcminit_mouse" Initializing "kcm_access" : "kcminit_access" Initializing "kcm_kgamma" : "kcminit_kgamma" QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty) , minor code: 0 kf5.kcoreaddons.kaboutdata: Could not initialize the equivalent properties of Q*Application: no instance (yet) existing. QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0 Qt: Session management error: networkIdsList argument is NULL
  • ~/.xfce4-session.verbose-log- XFCE4 desktop messages.

What to view - lnav

Almost everyone knows about the less utility and the tail -f command. The editor vim and file manager Midnight Commander. They all have their drawbacks: less doesn't handle logs with long strings well, mistaking them for binaries. Midnight Commander is only good for quick browsing when there is no need to search through a complex pattern and go back and forth a lot between matches. The vim editor understands and highlights the syntax of many formats, but if the log is updated frequently, distracting messages about changes to the file appear. However, this can easily be circumvented using<:view /path/to/file> .


Recently I discovered another useful and promising, but still slightly damp, utility - lnav, as transcribed by Log File Navigator.




Install the package as usual with one command.


$ aptitude install lnav #Debian/Ubuntu/LinuxMint $ yum install lnav #RedHat/CentOS $ dnf install lnav #Fedora $ emerge -av lnav #Gentoo, must be added to package.accept_keywords file $ yaourt -S lnav #Arch

Log Navigator lnav understands a range of file formats.

  • Access_log web server.
  • CUPS page_log
  • Syslog
  • dpkg.log
  • strace
  • Custom entries with timestamps
  • gzip, bzip
  • VMWare ESXi/vCenter Log

What does understanding file formats mean in this case? The trick is that lnav more than a utility for viewing text files. The program can do something else. You can open multiple files at once and switch between them.


(5:471)$ sudo lnav /var/log/pm-powersave.log /var/log/pm-suspend.log

The program can directly open an archive file.


(5:471)$ lnav -r /var/log/Xorg.0.log.old.gz

Shows a histogram of informative messages, warnings and errors when you press a key . This is from my syslog.


Mon May 02 20:25:00 123 normal 3 errors 0 warnings 0 marks Mon May 02 22:40:00 2 normal 0 errors 0 warnings 0 marks Mon May 02 23:25:00 10 normal 0 errors 0 warnings 0 marks Tue May 03 07:25:00 96 normal 3 errors 0 warnings 0 marks Tue May 03 23:50:00 10 normal 0 errors 0 warnings 0 marks Wed May 04 07:40:00 96 normal 3 errors 0 warnings 0 marks Wed May 04 08 :30:00 2 normal 0 errors 0 warnings 0 marks Wed May 04 10:40:00 10 normal 0 errors 0 warnings 0 marks Wed May 04 11:50:00 126 normal 2 errors 1 warnings 0 marks

In addition, syntax highlighting, tab addition and various useful features in the status bar are supported. Disadvantages include unstable behavior and freezing. Hope lnav will actively develop, very useful program In my opinion.

During its operation, the system monitors and saves in special files some events that it considers important or simply necessary for use in order to correct and debug errors, faulty configurations, etc. The files in which these events are stored are called log files or registration files . Often, logging files take up too much disk space, which can indicate a system malfunction, configuration errors, or simply incorrect configuration of the event logging daemons that monitor and collect everything. Thus, working with an event registration system is an important component in the work of any system administrator, on which the quality of system service and, as a result, their reliability and durability entirely depend.

How does the event registration system work?

Experienced system administrators know that it is necessary to review and analyze registration logs (files) regularly and with special care. The information contained in the logs often helps to quickly resolve problems or identify hidden problems in the system configuration. To track events by the system, check logs, record, store, archive and delete information from these logs, special regulations must be developed and approved for the organization operating and/or maintaining systems, servers and networks.

The main event logging tool in UNIX and Linu still remains syslogd daemon Syslog systems. But you should also keep in mind that for a long time, due to the variety of various branches of UNIX and Linux versions Many software packages, service scripts, and network daemons use their own logs, sometimes with exotic formats.

In general, the Syslog system (and other specialized programs) intercepts the monitored event and registers it in a log file. The registered event itself is a line of text containing data about the date/time, type, and severity of the event. Depending on the situation, this set may also include other data. The line of the registered event itself is broken up by separating characters: spaces, tabs, and punctuation marks to highlight the specified components.

Logs are easy to view because they are plain text files. For efficient work with magazines the most standard tools from the basic distribution of any distribution - commands and . If you need to comb through very large and complex logs, then you can (and even need) instead of the grep utility use another tool that is much more productive and flexible in such tasks - the . The text processing language Perl is also very well suited for this.

A typical Syslog system log entry typically looks like this:

Dec 18 15:12:42 backup.main.superhosting.ru sbatchd: sbatchd/main: ls_info() failed: LIM is down; try later; trying ... Dec 18 15:14:28 system.main.superhosting.ru pop-proxy: Connection from 186.115.198.84 Dec 18 15:14:30 control.main.superhosting.ru pingem : office.main.superhosting.ru has not answered 42 times Dec 18 15:15:05 service.main.superhosting.ru vmunix: Multiple softerrors: Seen 100Corrected Softerrors from SIMM J0201 Dec 18 15:15:16 backup.main.superhosting.ru PAM_unix: (sshd) session closed "for user trent

In this case, you can see that one of the Syslog logs contains events from several sources: sbathd, pingem, pop-proxy programs. You can also see that events are logged for several hosts interacting with this system: backup, system, office and service.

log files and their location in Linux

As noted, UNIX and Linux systems do not have clear conventions about where and how logs should be stored. They can be scattered throughout the entire file system, so it is important for each administrator to immediately understand where and for which packages and daemons the corresponding log files are located. But despite the lack of clear formal regulations regarding where logs are stored, there is still a traditional rule that these files should be located in the /var/log, /var/log/syslog, and also in /var/adm directories.

As a rule, only the superuser is granted access to read files in specified directories, but there is nothing wrong with setting up a more “democratic” access mode for frequently viewed logs that also do not contain important system information. Typically, this option is also used for convenience and to save time when you need to frequently and regularly examine some logs, for example for the Apache web server, which are usually located in /var/log/apache2 or /var/log/httpd.

It is also worth remembering that there are cases when (especially on faulty configurations) the total volume of log files increases sharply, and there is a high risk of crashing the system. For ease of monitoring free space on storage devices, as well as for reliability, the /var directory is often placed in a separate file system on a separate section.

Some special log files

The following table provides information about some log files, the information from which is very useful for system administration:

File Program Place Frequency Systems Purpose
acpid acpid F 64k RZ Power System Events
auth.log sudo and others S M U Authorization information
apache2/* httpd or apache2 F D ZU Apache Web Server Logs
apt* APT F M U Package installers
boot.log Launch scripts F M R Launch script logs
boot.msg Core IN - Z Kernel message buffer image
cron cron S N RAH Logs and information about the cron daemon
cups/* CUPS F N ZRU Messages related to the printing system
daemon.log Miscellaneous S N U Demon Tool Messages
debug Miscellaneous S D U Debugging messages
dmesg Core IN - RU Kernel message buffer image
dpkg.log dpkg F M U Package installers
faillog login N N RZU Information about failed authorization attempts
apache2/* Httpd or apache2 F D R Apache web server logs for /etc directory
kern.log login IN - RZ All kernel tool messages
lastlog login IN - RZ Last login time for each user (this file is binary)
mail* Email programs S N All Electronic communications
messages Miscellaneous S N RZUS
rpmpkgs cron.daily IN D R List of installed RPM packages
samba/* smbd and others F N - Information about the Samba server
secure sshd and others S M R Confidential authorization messages
sulog su F - SAH Information about successful and unsuccessful attempts to use the su command
syslog* Miscellaneous S H SUH Main system log file
warn wpar S H Z System warning/error level events
wpars/* wpar F - A Boot partition event information
wtmp login IN M All System registration messages (binary file)
xen/* Xen F 1m RZU Information from the monitor virtual machines Xen
Xorg.n.log Xorg F N R.S. X Windows Server Error Messages
yum.log yum F M R Package management log

The following designations apply for this table: S - Syslog, B - built-in name, F - configuration file, D - daily, N - weekly, M - monthly, NN - size in kilobytes or megabytes, Z - SUSE, R - Red Hat and CentOS, S - Solaris, H - HP-UX, A - AIX. The Frequency column indicates the frequency with which outdated information related to time or file size is deleted. The Program column indicates the program that created the file.

It should also be noted that most of the messages for the files presented in the table are sent to the Syslog system. The severity level and the program that creates the file are specified in the /etc/initlog.conf configuration file. - this is how the Syslog system works. The faillog file is binary and can therefore be read by the failog utility.

If you find an error, please highlight a piece of text and click Ctrl+Enter.

Since this is a constant question for new users on Linux forums, this post is dedicated to them.

New to the Linux forum.
// read in tongue twister //

Help the telepaths!
Tell me about the iron
Tell us about the system
Without hiding anything.

In this noble cause
May damsage help you *
Together with Elespisiai**
Don't forget about uname ***

Don't hide your logs
And configs, by the way, too,
And post it on the forum
With screenshots for a couple.

And then it’s amazing
Aksakals of Unixway
They will help and advise you,
How to fix the system.

----------------------
*meaning dmesg
** lspci command output
*** command uname -a


Why are log files needed and why are they important?

Normal [?] operating systems keep a detailed log of their own actions, recording everything that happens in text files, log files, log files or logs. These are ordinary text files that can be read by anyone text editor(or by means of the operating system itself), although many logs are readable only by the root user.
Main: Using the logs, you can reconstruct an almost complete picture of the problem, simultaneously finding out the features of your hardware and the degree of its support.

Here's what log files look like on Linux:

usbcore: registered new interface driver hidden
input: Logitech USB Receiver as /class/input/input1
input: USB HID v1.11 Mouse on usb-0000:00:1d.0-1
input: Logitech USB Receiver as /class/input/input2
input,hiddev96: USB HID v1.11 Device on usb-0000:00:1d.0-1
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
usb 1-5: new high speed USB device using ehci_hcd and address 3
usb 1-5: configuration #1 chosen from 1 choice
scsi0: SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
scsi 0:0:0:0: Direct-Access ChipsBnk SD/MMCReader 4081 PQ: 0 ANSI: 2




sd 0:0:0:0: 499712 512-byte hardware sectors (256 MB)
sd 0:0:0:0: Write Protect is off
sd 0:0:0:0: Mode Sense: 0b 00 00 08
sd 0:0:0:0: Assuming drive cache: write through
sda: sda1 sda2
sd 0:0:0:0: Attached SCSI removable disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete
From this piece of log it is clear that two events occurred:
  • mouse connected (highlighted in purple):input: USB HID v1.11 Mouse on usb-0000:00:1d.0-1 and most likely this mouse is wireless (this is indicated byUSB Receiver)
  • connected a USB drive (highlighted in green):usb 1-5: new high speed USB device using ehci_hcd and address 3, which is recognized as a USB drivescsi0: SCSI emulation for USB Mass Storage devices with a capacity of 256MBsd 0:0:0:0: 499712 512-byte hardware sectors (256 MB) and containing two partitions (two sections with data)sda: sda1 sda2.
As you can see, you can extract a huge amount of details about the operation of the equipment from log files. Other log files may contain error messages and often recipes for what you can try to fix them.

Where are log files stored in Linux?

All log files should be in one directory, which is located here:
In general, quite logical. But you don’t have to go there: we remember that the console is our friend and a powerful weapon in the right hands. In order to quickly receive logs and attach them to a message to the forum / publication / sending by mail, do this:
  1. From the console:
    1. V graphic mode- in the program menu it can be called xterm, terminal, konsole, bash.
    2. in console mode - if you see a black screen in front of you with words like penta4@penta4rce:~$ You don’t need to do anything yet - you’re already in the console :-)
  2. Next we write:
    1. dmesg > dmesg.txt
    2. lspci -v > lspci.txt
    3. cp /var/log/X.org.0.log ~/
  3. Next we see the files dmesg.txt and lspci.txt and X.org.0.log in our home directory
These are the files they so insistently seek from you on the forums. The presence of logs, along with detailed description problems and a reasonable number of screenshots can radically quickly receive a competent and comprehensive answer (and even more often, a direct link to the solution).

For a more detailed study of the problem and to clarify the operating features of the equipment, you can use the working methods that are wonderfully described