For cliens
For partners
Knowledge base
Simple instructions to work with the ProfitServer service
How to read logs in Linux and where to find it

When you face any problems with your server’s performance, the first thing you want to do is to check your Linux logs. In the system log, you can find some helpful diagnostics messages from different components of the operating system like the kernel or various services, so you’ll most likely find the failure cause there.

Every message in the log is generated in the result of certain events in the operating system: from the user, authorization to service shut-down or application failure. These events have different priorities depending on how critical they are. There are following types of events in Linux:

  1. emerg - failure, highest priority;
  2. alert - urgent warning;
  3. crit - critical event;
  4. err - ordinary error;
  5. warn - ordinary warning;
  6. notice - notification;
  7. info - information message;
  8. debug - debugging information;

At the moment, the main logs harvesting services in Linux are rsyslog and systemd-journald. They go with most of the modern distribution packages and work independently.


Logs of this service are located in “/var/log/” folder in the form of ordinary text files. Log messages are put in different files depending on the type of event. For instance, “/var/log/auth.log” contains information on users’ authorization in the system, and “/var/log/kern.log” contains kernel messages. Files names can differ across distribution packages, so let’s take a look at the config file to get the idea of what’s where “/etc/rsyslog.d/50-default.conf”.

Сбор логов Linux утилитой rsyslog

These rules display which file contains each type of log messages. The left part displays the type of message in the following form “[Source].[Priority]” and the right part displays the name of the log file. While writing the type of message “*” character can be added to. It means empty value or “none” that removes it from the list. Let’s take a closer look at the first two rules.

“auth,authpriv.* /var/log/auth.log”
“*.*;auth,authpriv.none -/var/log/syslog”

The first rule means that all messages received from the authorization mechanism will be recorded into “/var/log/auth.log” file. All authorization attempts (both successful and not) will be registered in this file. The second rule indicates that all messages except ones connected with authorization will be recorded into “/var/log/syslog” file. These two files are usually the most popular. The following rules define the path to store kernel logs “kern.*” and mail service logs “mail.*

Log files can be opened with the help of any text editor, like less, cat, tail. Let’s open the “/var/log/auth.log” file

less /var/log/auth.log

Утилита less

Every line of the file is a separate message received from the application or service. All messages regardless of their source have one format and consist of 5 parts. Let’s take the highlighted message in the screenshot as an example.

  1. Message timestamp - “Feb 12 06:18:33”
  2. Name of the computer that sent the message - “vds”
  3. Name of the application or service that sent the message - “sshd”
  4. Process ID - [653]
  5. Message text - “Accepted password for mihail from port 2849 ssh2”

This was an example of a successful connection to SSH.

And here’s how an unsuccessful login attempt looks:

Запись в лог-файле Линукс о неудачной попытке авторизации SSH

This file also records commands with advanced permissions

Читаем логи Linux

Let’s open the /var/log/syslog file

Как правильно прочитать лог Linux

A highlighted message on the screenshot is the message about the network interface shutdown.

For searching for information through long text files use grep utility. You can find all messages received from pptpd service in the “/var/log/syslog” file.

grep 'pptpd' /var/log/syslog

Используем утилиту grep для поиска информации в больших файлах логов

During the diagnostics you can use tail utility that can display several last lines of files. Command “tail -f /var/log/syslog” will let you watch logs recording in real-time.

The service rsyslog is very flexible and powerful. It can be used for harvesting logs in local systems as well as on the enterprise level. You can find full documentation on the official website

Logs rotation in Linux

Log recording is happening continuously, so the size of the files constantly grows. Rotation mechanism ensures automatic archiving of old logs and the creation of new files. Depending on the rules, it can happen daily, weekly, monthly or by size limit. As new logs are created, old ones can be just deleted or sent by email. Logs rotation is performed by logrotate utility. You can find the main configuration in “/etc/logrotate.conf” file. Files content is also processed in “/etc/logrotate.d/” folder

New rules can be logged into the main config file. However, it’s best to create a separate file in “/etc/logrotate.d/”. By default, there are a few files in this directory

Утилита logorotate

Let’s take a look at the file “/etc/logrotate.d/rsyslog" that contains rotation rules for logs of the rsyslog service.

файл “/etc/logrotate.d/rsyslog”

First, the rule should contain the path to the log file and then go all guidelines in curved brackets.

  • rotate 7 - number of files to keep - 7
  • daily - create a new file every day
  • compress - compress and archive old files

Настраиваем ротацию логов в Линукс

You can see on the screenshot that in the “/var/log/” folder there are the main log “syslog” and 7 archives, which corresponds with the rules in the config file.

You can find a more detailed description of logrotate in the manual, executing the “man logrotate” command


Logs harvesting service systemd-journald is a part of the initialization system systemd. Linux log files are stored in “/var/log/journal/” in a special format and can be opened with the help of journalctl utility. Records format is exactly the same as in rsyslog.

Command journalctl with no attributes shows all records but it’s not suitable for bigger logs. Let’s take a look at some options of this utility.

  • show all records since the last start
    journalctl -b
  • show record within a certain time period
    journalctl -S "2020-02-17 12:00" -U "2020-02-17 12:10"
  • show records of a certain service
    journalctl -u pptpd
  • show kernel messages
    journalctl -k
  • show messages of a certain priority, higher priority messages in this case(crit, alert, emerg).
    journalctl -p err
  • show messages in real-time
    journalctl -f

For better flexibility you can combine these options. Let’s show all errors of the pptpd service

journalctl -u pptpd -p err

Пример вывода всех ошибок pptpd в лог-файлах

If you specify the path to the executable file as an attribute the utility will show all messages sent by this file. Let’s show all messages sent by the file “/usr/bin/sudo” since 04:15 on February 18, 2020. In fact, it will show all commands executed with higher permissions.

journalctl -S "2020-02-18 04:15" /usr/bin/sudo

Учимся читать логи Линукс

To find out how much disk space log files take up to execute the following command

journalctl --disk-usage

In order to limit the log file to 1Gb execute the following command

journalctl --vacuum-size=1G

Opening binary files

Now let’s take a look at some special files in the “/var/log/” folder where all login attempts are stored. These files are binary and can be opened with special programs only.

/var/log/wtmp contains information on successful login attempts. Use last utility to open it.

утилита last

/var/log/btmp - contains all failed login attempts. It can be opened with lastb with advanced permissions. Attribute -n defines the number of lines displayed from the end of the file.

командой lastb

/var/log/lastlog - contains the time of the last login action for every account record. It can be opened with lastlog

утилита lastlog

Please, rate this article:
Ask a question
We are always ready to answer your questions at any time of day or night.
Please, check our Knowledge base, most likely the answer to your question is already there!