4.3 Урок 2

Сертифікат:

Linux Essentials

Версія:

1.6

Розділ:

4 Операційна система Linux

Тема:

4.3 Місце збереження даних

Урок:

2 of 2

Вступ

Після вивчення програм та їх конфігураційних файлів у цьому уроці ми дізнаємося, як команди виконуються у якості процесів. Аналогічно, ми будемо коментувати системний обмін повідомленнями, використання кільцевого буфера ядра та те, як поява systemd та його демона журналу — journald — змінили попередній порядок ведення журналів в системі.

Процеси

Кожен раз, коли користувач вводить команду, запускається програма і генерується один або кілька процесів.

Процеси мають ієрархічну структуру. Після того, як ядро завантажується в пам’ять під час завантаження системи, ініціюється перший процес, який, у свою чергу, запускає інші процеси, які, знову ж таки, можуть запускати інші процеси. Кожен процес має унікальний ідентифікатор (PID) та ідентифікатор батьківського процесу (PPID). Це цілі додатні числа, які призначаються в послідовному порядку.

Динамічне дослідження процесів: `top`

Ви можете отримати динамічний список всіх запущених процесів за допомогою команди top:

$ top

top - 11:10:29 up  2:21,  1 user,  load average: 0,11, 0,20, 0,14
Tasks:  73 total,   1 running,  72 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,0 us,  0,3 sy,  0,0 ni, 99,7 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem :  1020332 total,   909492 free,    38796 used,    72044 buff/cache
KiB Swap:  1046524 total,  1046524 free,        0 used.   873264 avail Mem

   PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
   436 carol     20   0   42696   3624   3060 R  0,7  0,4   0:00.30 top
     4 root      20   0       0      0      0 S  0,3  0,0   0:00.12 kworker/0:0
   399 root      20   0   95204   6748   5780 S  0,3  0,7   0:00.22 sshd
     1 root      20   0   56872   6596   5208 S  0,0  0,6   0:01.29 systemd
     2 root      20   0       0      0      0 S  0,0  0,0   0:00.00 kthreadd
     3 root      20   0       0      0      0 S  0,0  0,0   0:00.02 ksoftirqd/0
     5 root       0 -20       0      0      0 S  0,0  0,0   0:00.00 kworker/0:0H
     6 root      20   0       0      0      0 S  0,0  0,0   0:00.00 kworker/u2:0
     7 root      20   0       0      0      0 S  0,0  0,0   0:00.08 rcu_sched
     8 root      20   0       0      0      0 S  0,0  0,0   0:00.00 rcu_bh
     9 root      rt   0       0      0      0 S  0,0  0,0   0:00.00 migration/0
    10 root       0 -20       0      0      0 S  0,0  0,0   0:00.00 lru-add-drain
    (...)

Як можна побачити вище, top також може надати нам інформацію про використання пам’яті та процесора системою в цілому, а також для кожного процесу окремо.

top дозволяє користувачеві певну взаємодію.

За замовчуванням вихідні дані сортуються за відсотком часу центрального процесора, який використовується кожним процесом, у порядку спадання. Цю поведінку можна змінити, натиснувши наступні клавіші в межах top:

M: Сортувати за використанням пам’яті.
N: Сортувати за ідентифікатором процесу.
T: Сортувати за часом роботи.
P: Сортувати за відсотком використання ЦП.

Щоб перемикатися між варіантами за спаданням/за збільшенням, просто натисніть R.

Більш зручною версією top є htop. Інша - можливо, більш вичерпна альтернатива - atop. Якщо вони ще не встановлені у вашій системі, я рекомендую вам скористатися диспетчером пакунків, щоб встановити їх і спробувати.

Миттєвий знімок процесів: `ps`

Іншою дуже корисною командою для отримання інформації про процеси є ps. Тоді як top надає динамічну інформацію, ps надає статичну.

Якщо викликати ps без параметрів, вихідні дані будуть досить дискретними і стосуватимуться лише процесів, що відносяться до поточної оболонки:

$ ps
  PID TTY          TIME CMD
 2318 pts/0    00:00:00 bash
 2443 pts/0    00:00:00 ps

Інформація, що відображається, пов’язана з ідентифікатором процесу (PID), терміналом, на якому виконується процес (TTY), часом процесора, затраченого процесом (TIME), та командою, яка запустила процес (CMD).

Корисним перемикачем для ps є -f, який показує повноформатний список:

$ ps -f
UID        PID  PPID  C STIME TTY          TIME CMD
carol     2318  1682  0 08:38 pts/1    00:00:00 bash
carol     2443  2318  0 08:46 pts/1    00:00:00 ps -f

У поєднанні з іншими перемикачами -f показує зв’язок між батьківським і дочірнім процесами:

$ ps -uf
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
carol       2318  0.0  0.1  21336  5140 pts/1    Ss   08:38   0:00 bash
carol       2492  0.0  0.0  38304  3332 pts/1    R+   08:51   0:00  \_ ps -uf
carol       1780  0.0  0.1  21440  5412 pts/0    Ss   08:28   0:00 bash
carol       2291  0.0  0.7 305352 28736 pts/0    Sl+  08:35   0:00  \_ emacs index.en.adoc -nw
(...)

Аналогічно, ps може показувати відсоток пам’яті, що використовується, якщо під час виклику використовувати перемикач -v:

$ ps -v
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
 1163 tty2     Ssl+   0:00      1    67 201224 5576  0.1 /usr/lib/gdm3/gdm-x-session (...)
 (...)

Note	Іншою візуально привабливою командою, яка показує ієрархію процесів, є `pstree`. Вона входить до всіх основних дистрибутивів.

Інформація про процеси у каталозі `/proc`

Ми вже бачили файлову систему /proc. /proc містить нумерований підкаталог для кожного запущеного процесу в системі (номер є PID процесу):

carol@debian:~# ls /proc
1    108  13   17   21   27   354  41   665  8    9
10   109  14   173  22   28   355  42   7    804  915
103  11   140  18   23   29   356  428  749  810  918
104  111  148  181  24   3    367  432  75   811
105  112  149  19   244  349  370  433  768  83
106  115  15   195  25   350  371  5    797  838
107  12   16   2    26   353  404  507  798  899
(...)

Таким чином, вся інформація про певний процес міститься в його каталозі. Давайте виведемо вміст першого процесу - того, чий PID дорівнює 1 (вихід був скорочений для читабельності):

# ls /proc/1/
attr        cmdline          environ  io        mem	      ns
autogroup   comm             exe      limits    mountinfo numa_maps
auxv        coredump_filter  fd       loginuid  mounts    oom_adj
...

Ви можете перевірити, наприклад, виконуваний файл процесу:

# cat /proc/1/cmdline; echo
/sbin/init

Як бачите, двійковим файлом, який почав ієрархію процесів, був /sbin/init.

Note	Команди можуть бути об’єднані крапкою з комою (`;`). Суть використаної вище команди `echo` полягає в тому, щоб забезпечити перехід на новий рядок. Спробуйте просто запустити `cat /proc/1/cmdline`, щоб побачити різницю.

Завантаження системи

Кожен процес у системі потенційно може використовувати системні ресурси. Так зване системне навантаження намагається об’єднати загальне навантаження системи в єдиний числовий показник. Ви можете побачити поточне навантаження за допомогою команди uptime:

$ uptime
 22:12:54 up 13 days, 20:26,  1 user,  load average: 2.91, 1.59, 0.39

Три останні цифри вказують на середнє навантаження системи за останню хвилину (2,91), останні п’ять хвилин (1,59) і останні п’ятнадцять хвилин (0,39) відповідно.

Кожне з цих чисел вказує, скільки процесів чекали на завершення ресурсів ЦП або операцій введення/виведення. Це означає, що ці процеси були готові до запуску при отриманні відповідних ресурсів.

Системні журнали та системні повідомлення

Як тільки ядро і процеси починають виконуватися та взаємодіяти один з одним, виробляється багато інформації. Більшість інформації надсилається до файлів - так звані файли журналів або, просто, logs.

Без ведення журналу пошук події, що відбулися на сервері, створив би системним адміністраторам багато головного болю, тому важливо мати стандартизований і централізований спосіб відстеження будь-яких системних подій. Крім того, журнали є визначальними та показовими, коли справа доходить до усунення несправностей та безпеки, а також надійних джерел даних для розуміння системної статистики та прогнозування тенденцій.

Реєстрація за допомогою демона системного журналу

Традиційно системними повідомленнями керує стандартний засіб ведення журналу - syslog - або будь-який з його похідних - syslog-ng або rsyslog. Демон реєстрації збирає повідомлення від інших служб і програм і зберігає їх у файлах журналів, зазвичай у /var/log. Однак деякі служби піклуються про власні журнали (наприклад, веб-сервер Apache HTTPD). Аналогічно, ядро Linux використовує кільцевий буфер у пам’яті для зберігання своїх повідомлень журналу.

Файли журналів у `/var/log`

Оскільки журнали – це дані, які змінюються з часом, вони зазвичай знаходяться в /var/log.

Якщо ви дослідите /var/log, ви зрозумієте, що назви журналів - до певної міри - цілком зрозумілі. Деякі приклади включають:

/var/log/auth.log: Зберігає інформацію про аутентифікацію.
/var/log/kern.log: Зберігає інформацію про ядро.
/var/log/syslog: Зберігає системну інформацію.
/var/log/messages: Зберігає дані системи та програм.

Note	Точні назви та вміст файлів журналів можуть відрізнятися в різних дистрибутивах Linux.

Доступ до файлів журналу

Досліджуючи файли журналів, не забувайте про необхідність зайти з правами root (якщо у вас немає прав на читання) і використовуйте команду перегляду файлів, наприклад less:

# less /var/log/messages
Jun  4 18:22:48 debian liblogging-stdlog:  [origin software="rsyslogd" swVersion="8.24.0" x-pid="285" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Jun 29 16:57:10 debian kernel: [    0.000000] Linux version 4.9.0-8-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.130-2 (2018-10-27)
Jun 29 16:57:10 debian kernel: [    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-8-amd64 root=/dev/sda1 ro quiet

Крім того, ви можете використовувати tail з перемикачем -f для читання останніх повідомлень файлу та динамічного показу нових рядків у міру їх додавання:

# tail -f /var/log/messages
Jul  9 18:39:37 debian kernel: [    2.350572] RAPL PMU: hw unit of domain psys 2^-0 Joules
Jul  9 18:39:37 debian kernel: [    2.512802] input: VirtualBox USB Tablet as /devices/pci0000:00/0000:00:06.0/usb1/1-1/1-1:1.0/0003:80EE:0021.0001/input/input7
Jul  9 18:39:37 debian kernel: [    2.513861] Adding 1046524k swap on /dev/sda5.  Priority:-1 extents:1 across:1046524k FS
Jul  9 18:39:37 debian kernel: [    2.519301] hid-generic 0003:80EE:0021.0001: input,hidraw0: USB HID v1.10 Mouse [VirtualBox USB Tablet] on usb-0000:00:06.0-1/input0
Jul  9 18:39:37 debian kernel: [    2.623947] snd_intel8x0 0000:00:05.0: white list rate for 1028:0177 is 48000
Jul  9 18:39:37 debian kernel: [    2.914805] IPv6: ADDRCONF(NETDEV_UP): enp0s3: link is not ready
Jul  9 18:39:39 debian kernel: [    4.937283] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Jul  9 18:39:39 debian kernel: [    4.938493] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s3: link becomes ready
Jul  9 18:39:40 debian kernel: [    5.315603] random: crng init done
Jul  9 18:39:40 debian kernel: [    5.315608] random: 7 urandom warning(s) missed due to ratelimiting

Ви отримаєте вихідні дані у такому форматі:

Позначка часу.
Ім’я хоста, з якого надійшло повідомлення.
Назва програми/служби, яка створила повідомлення.
PID програми, яка створила повідомлення.
Опис дії, що відбулася.

Більшість файлів журналів ведуться у вигляді простого тексту; однак деякі з них можуть містити двійкові дані, як у випадку з /var/log/wtmp, який зберігає дані, що стосуються успішного входу. Ви можете використовувати команду file, щоб зрозуміти, що це саме так:

$ file /var/log/wtmp
/var/log/wtmp: dBase III DBT, version number 0, next free block index 8

Ці файли зазвичай можна прочитати за допомогою спеціальних команд. last використовується для інтерпретації даних у /var/log/wtmp:

$ last
carol    tty2         :0               Thu May 30 10:53   still logged in
reboot   system boot  4.9.0-9-amd64    Thu May 30 10:52   still running
carol    tty2         :0               Thu May 30 10:47 - crash  (00:05)
reboot   system boot  4.9.0-9-amd64    Thu May 30 09:11   still running
carol    tty2         :0               Tue May 28 08:28 - 14:11  (05:42)
reboot   system boot  4.9.0-9-amd64    Tue May 28 08:27 - 14:11  (05:43)
carol    tty2         :0               Mon May 27 19:40 - 19:52  (00:11)
reboot   system boot  4.9.0-9-amd64    Mon May 27 19:38 - 19:52  (00:13)
carol    tty2         :0               Mon May 27 19:35 - down   (00:03)
reboot   system boot  4.9.0-9-amd64    Mon May 27 19:34 - 19:38  (00:04)

Note	Подібно до `/var/log/wtmp`, `/var/log/btmp` зберігає інформацію про невдалі спроби входу, і спеціальною командою для читання його вмісту є `lastb`.

Ротація журналу

Файли журналів можуть значно збільшуватися за кілька тижнів або місяців і займати весь вільний дисковий простір. Щоб вирішити цю проблему, використовується утиліта logrotate. Вона реалізує ротацію журналів або циклічну зміну, що передбачає такі дії, як переміщення файлів журналів під нове ім’я, їх архівування та/або стиснення, іноді надсилання їх електронною поштою системному адміністратору та в кінцевому підсумку видалення їх, коли вони старіють. Умови, що використовуються для іменування цих переміщених файлів журналів, різноманітні (наприклад, додавання суфікса з датою); однак і просто додавання суфікса з цілим числом є звичайним явищем:

# ls /var/log/apache2/
access.log  error.log  error.log.1  error.log.2.gz  other_vhosts_access.log

Note how error.log.2.gz has already been compressed with gzip (hence the .gz suffix).

Кільцевий буфер ядра

Кільцевий буфер ядра — це структура даних фіксованого розміру, яка записує повідомлення про завантаження ядра, а також будь-які поточні повідомлення ядра. Функція цього буфера - дуже важлива - полягає в реєстрації всіх повідомлень ядра, створених під час завантаження, коли syslog ще недоступний. Команда dmesg друкує кільцевий буфер ядра (який раніше також зберігався в /var/log/dmesg). Через розширення кільцевого буфера ця команда зазвичай використовується в поєднанні з утилітою фільтрації тексту grep або командою читання файлів, такою як less. Наприклад, для пошуку повідомлень про завантаження:

$ dmesg | grep boot
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-amd64 root=UUID=5216e1e4-ae0e-441f-b8f5-8061c0034c74 ro quiet
[    0.000000] smpboot: Allowing 1 CPUs, 0 hotplug CPUs
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-amd64 root=UUID=5216e1e4-ae0e-441f-b8f5-8061c0034c74 ro quiet
[    0.144986] AppArmor: AppArmor disabled by boot time parameter
(...)

Note	Оскільки кільцевий буфер ядра з часом збільшується новими повідомленнями, найстаріші зникатимуть.

Системний журнал: systemd-journald

Станом на 2015 рік systemd замінив SysV Init як де факто менеджер системи та служб у більшості основних дистрибутивів Linux. Як наслідок, демон журналу — journald — став стандартним компонентом журналу, замінивши системний журнал у більшості аспектів. Дані більше не зберігаються у вигляді простого тексту, а в двійковій формі. Таким чином, утиліта journalctl необхідна для читання журналів. Крім того, journald сумісна з системним журналом і може бути інтегрована з syslog.

journalctl – це утиліта, яка використовується для читання та запитів до бази даних журналу systemd. Якщо викликати її без параметрів, вона надрукує весь журнал:

# journalctl
-- Logs begin at Tue 2019-06-04 17:49:40 CEST, end at Tue 2019-06-04 18:13:10 CEST. --
jun 04 17:49:40 debian systemd-journald[339]: Runtime journal (/run/log/journal/) is 8.0M, max 159.6M, 151.6M free.
jun 04 17:49:40 debian kernel: microcode: microcode updated early to revision 0xcc, date = 2019-04-01
Jun 04 17:49:40 debian kernel: Linux version 4.9.0-8-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) )
Jun 04 17:49:40 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-8-amd64 root=/dev/sda1 ro quiet
(...)

Однак, якщо її викликати з використанням перемикачів -k або --dmesg, це буде еквівалентно використанню команди dmesg:

# journalctl -k
[    0.000000] Linux version 4.9.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.168-1+deb9u2 (2019-05-13)
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-amd64 root=UUID=5216e1e4-ae0e-441f-b8f5-8061c0034c74 ro quiet
(...)

Інші цікаві параметри для journalctl включають:

-b, --boot: Показує інформацію про завантаження.
-u: Показує повідомлення про вказаний блок. Цей блок можна визначити як будь-який ресурс, який обробляє systemd. Наприклад, journalctl -u apache2.service використовується для читання повідомлень про веб-сервер apache2.
-f: Показує останні повідомлення журналу та продовжує друкувати нові записи, коли вони додаються до журналу - так само як tail -f.

Вправи до посібника

Перегляньте наведені нижче результати команди top і дайте відповідь на такі запитання:

carol@debian:~$ top

top - 13:39:16 up 31 min,  1 user,  load average: 0.12, 0.15, 0.10
Tasks:  73 total,   2 running,  71 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.1 us,  0.4 sy,  0.0 ni, 98.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  1020332 total,   698700 free,   170664 used,   150968 buff/cache
KiB Swap:  1046524 total,  1046524 free,        0 used.   710956 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
  605 nobody    20   0 1137620 132424  34256 S  6.3 13.0   1:47.24 ntopng
  444 www-data  20   0  364780   4132   2572 S  0.3  0.4   0:00.44 apache2
  734 root      20   0   95212   7004   6036 S  0.3  0.7   0:00.36 sshd
  887 carol     20   0   46608   3680   3104 R  0.3  0.4   0:00.03 top
    1 root      20   0   56988   6688   5240 S  0.0  0.7   0:00.42 systemd
    2 root      20   0       0      0      0 S  0.0  0.0   0:00.00 kthreadd
    3 root      20   0       0      0      0 S  0.0  0.0   0:00.09 ksoftirqd/0
    4 root      20   0       0      0      0 S  0.0  0.0   0:00.87 kworker/0:0
(...)

Які процеси були запущені користувачем carol?
Який віртуальний каталог /proc слід відвідати для пошуку даних щодо команди top?
Який процес був запущений першим? Як це можна визначити?
Заповніть таблицю, вказавши, в якій області виведення top міститься наступна інформація:

Інформація про … Підсумкова область Область завдань

Memory

Swap

PID

CPU time

Commands

Яка команда використовується для читання наступних двійкових журналів?
- /var/log/wtmp
- /var/log/btmp
- /run/log/journal/2a7d9730cd3142f4b15e20d6be631836/system.journal
У поєднанні з grep, які команди ви б використали, щоб дізнатися таку інформацію про вашу систему Linux?
- Коли система востаннє перезавантажувалася (wtmp)
- Які жорсткі диски встановлені (kern.log)
- Коли відбувся останній вхід (auth.log)
Які дві команди ви б використали для відображення кільцевого буфера ядра?
Вкажіть, де знаходяться наступні повідомлення журналу:
- Jul 10 13:37:39 debian dbus[303]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
  
  /var/log/auth.log
  
  /var/log/kern.log
  
  /var/log/syslog
  
  /var/log/messages
- Jul 10 11:23:58 debian kernel: [ 1.923349] usbhid: USB HID core driver
  
  /var/log/auth.log
  
  /var/log/kern.log
  
  /var/log/syslog
  
  /var/log/messages
- Jul 10 14:02:53 debian sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
  
  /var/log/auth.log
  
  /var/log/kern.log
  
  /var/log/syslog
  
  /var/log/messages
- Jul 10 11:23:58 debian NetworkManager[322]: <info> [1562750638.8672] NetworkManager (version 1.6.2) is starting…
  
  /var/log/auth.log
  
  /var/log/kern.log
  
  /var/log/syslog
  
  /var/log/messages
Чи містять результати запиту journalctl інформацію про наступне?

Модуль Команда

ssh

networking

rsyslog

cron

Дослідницькі вправи

Перегляньте результат команди top з вправ до посібника і дайте відповідь на такі запитання:
- Які два кроки ви б виконали, щоб завершити процес веб-серверу apache?
- Як ви можете відобразити інформацію про фізичну та віртуальну пам’ять за допомогою індикаторів прогресу в області підсумків?
- Тепер відсортуйте процеси за використанням пам’яті:
- Тепер, коли інформація про пам’ять відображається в індикаторах виконання, а процеси, відсортовані за використанням пам’яті, збережіть ці конфігурації, щоб отримати їх за замовчуванням наступного разу, коли ви використовуєте top:
- У якому файлі зберігаються налаштування конфігурації top? Де він розташований? Як перевірити його наявність?
Дізнайтеся про команду exec у оболонці Bash. Спробуйте продемонструвати її функціональність, запустивши сеанс Bash, знайшовши процес Bash за допомогою ps, потім запустіть exec /bin/sh і знову знайдіть процес з тим самим PID.
Виконайте ці кроки, щоб дослідити події ядра та динамічне керування пристроями udev:
- Вставте USB-накопичувач до включеного комп’ютера. Запустіть dmesg і зверніть увагу на останні рядки. Яка інформація в останньому рядку?
- Пам’ятаючи про результат попередньої команди, запустіть ls /dev/sd* і переконайтеся, що ваш USB-накопичувач з’являється у списку. Що ми бачимо у вихідних даних?
- Тепер вийміть USB-накопичувач і знову запустіть dmesg. Яка інформація в останньому рядку?
- Знову запустіть ls /dev/sd* і переконайтеся, що ваш пристрій зник зі списку. Що ми бачимо у вихідних даних?

Підсумки

У контексті зберігання даних на цьому уроці обговорювалися такі теми: керування процесами, системний журнал та обмін повідомленнями.

Щодо управління процесами, ми дізналися наступне:

Програми генерують процеси, а процеси мають ієрархічну структуру.
Кожен процес має унікальний ідентифікатор (PID) та ідентифікатор батьківського процесу (PPID).
top є дуже корисною командою для динамічного та інтерактивного дослідження запущених процесів системи.
ps можна використовувати для отримання знімків поточних запущених процесів у системі.
Каталог /proc містить каталоги для кожного запущеного процесу в системі, назви каталогів відповідають PID процесів.
Концепція середнього завантаження системи - це дуже корисна інформація для перевірки використання/перевантаження ЦП.

Що стосується системного журналу, ми повинні пам’ятати наступне:

Журнал – це файл, в якому записуються системні події. Журнали мають велику цінність, коли справа доходить до усунення несправностей.
Ведення журналу традиційно виконується спеціальними службами, такими як syslog, syslog-ng або rsyslog. Тим не менш, деякі програми використовують власні демони журналу.
Оскільки журнали є змінними даними, вони зберігаються в /var і - іноді - їх імена можуть дати вам підказку про їх вміст (kern.log, auth.log тощо).
Більшість журналів - це звичайні текстові файли і вони можуть бути прочитані будь-яким текстовим редактором, якщо у вас є відповідні дозволи. Однак деякі з них є двійковими і, щоб їх прочитати, потрібні спеціальні команди.
Щоб уникнути проблем із дисковим простором, ротація файлів журналу виконується утилітою logrotate.
Що стосується ядра, то воно використовує кругову структуру даних – кільцевий буфер – де зберігаються повідомлення про завантаження (старі повідомлення з часом зникають).
Менеджер системи та служб systemd замінив System V init практично у всіх дистрибутивах, а journald став стандартною службою журналу.
Щоб прочитати журнал systemd, потрібна утиліта journalctl.

Команди, які використовувалися в цьому уроці:

cat: Об’єднати/вивести вміст файлу.
dmesg: Друк кільцевого буферу ядра.
echo: Відображає рядок тексту або новий рядок.
file: Визначає тип файлу.
grep: Друкує рядки, що відповідають шаблону.
last: Показує список останніх користувачів, які ввійшли в систему.
less: Відображати вміст файлу по одній сторінці.
ls: Виводить вміст каталогу.
journalctl: Робить запит до журналу systemd.
tail: Відображає останні рядки файлу.

Відповіді до вправ посібника

Перегляньте наведені нижче результати команди top і дайте відповідь на такі запитання:

carol@debian:~$ top

top - 13:39:16 up 31 min,  1 user,  load average: 0.12, 0.15, 0.10
Tasks:  73 total,   2 running,  71 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.1 us,  0.4 sy,  0.0 ni, 98.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  1020332 total,   698700 free,   170664 used,   150968 buff/cache
KiB Swap:  1046524 total,  1046524 free,        0 used.   710956 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
  605 nobody    20   0 1137620 132424  34256 S  6.3 13.0   1:47.24 ntopng
  444 www-data  20   0  364780   4132   2572 S  0.3  0.4   0:00.44 apache2
  734 root      20   0   95212   7004   6036 S  0.3  0.7   0:00.36 sshd
  887 carol     20   0   46608   3680   3104 R  0.3  0.4   0:00.03 top
    1 root      20   0   56988   6688   5240 S  0.0  0.7   0:00.42 systemd
    2 root      20   0       0      0      0 S  0.0  0.0   0:00.00 kthreadd
    3 root      20   0       0      0      0 S  0.0  0.0   0:00.09 ksoftirqd/0
    4 root      20   0       0      0      0 S  0.0  0.0   0:00.87 kworker/0:0
(...)

Які процеси були запущені користувачем carol?

Відповідь: Тільки один: top.
Який віртуальний каталог /proc слід відвідати для пошуку даних щодо команди top?

Відповідь: /proc/887
Який процес був запущений першим? Як це можна визначити?

Відповідь: systemd. Тому що він має PID #1.

Заповніть таблицю, вказавши, в якій області виведення top міститься наступна інформація:

Інформація про… Підсумкова область Область завдань

Memory

Так

Swap

Так

Ні

PID

Ні

Так

CPU time

Так

Commands

Ні

Так

Яка команда використовується для читання наступних двійкових журналів?
- /var/log/wtmp
  
  Відповідь: last
- /var/log/btmp
  
  Відповідь: lastb
- /run/log/journal/2a7d9730cd3142f4b15e20d6be631836/system.journal
  
  Відповідь: journalctl
У поєднанні з grep, які команди ви б використали, щоб дізнатися таку інформацію про вашу систему Linux?
- Коли система востаннє перезавантажувалася (wtmp)
  
  Відповідь: last
- Які жорсткі диски встановлені (kern.log)
  
  Відповідь: less /var/log/kern.log
- Коли відбувся останній вхід (auth.log)
  
  відповідь: less /var/log/auth.log
Які дві команди ви б використали для відображення кільцевого буфера ядра?

dmesg та journalctl -k (також journalctl --dmesg).
Вкажіть, де знаходяться наступні повідомлення журналу:
- Jul 10 13:37:39 debian dbus[303]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
  
  /var/log/auth.log
  
  /var/log/kern.log
  
  /var/log/syslog
  
  X
  
  /var/log/messages
- Jul 10 11:23:58 debian kernel: [ 1.923349] usbhid: USB HID core driver
  
  /var/log/auth.log
  
  /var/log/kern.log
  
  X
  
  /var/log/syslog
  
  /var/log/messages
  
  X
  
  Jul 10 14:02:53 debian sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
  
  /var/log/auth.log
  
  X
  
  /var/log/kern.log
  
  /var/log/syslog
  
  /var/log/messages
- Jul 10 11:23:58 debian NetworkManager[322]: <info> [1562750638.8672] NetworkManager (version 1.6.2) is starting…
  
  /var/log/auth.log
  
  /var/log/kern.log
  
  /var/log/syslog
  
  /var/log/messages
  
  X
Чи містять результати запиту journalctl інформацію про наступне?

Модуль Команда

ssh

journalctl -u ssh.service

networking

journalctl -u networking.service

rsyslog

journalctl -u rsyslog.service

cron

journalctl -u cron.service

Відповіді до дослідницьких вправ

Перегляньте результат команди top з вправ до посібника і дайте відповідь на такі запитання:
- Які два кроки ви б виконали, щоб завершити процес веб-серверу apache?
  
  Спочатку натиснути k; потім надати значення kill.
- Як ви можете відобразити інформацію про фізичну та віртуальну пам’ять за допомогою індикаторів прогресу в області підсумків?
  
  Натиснувши m один раз або двічі.
- Тепер відсортуйте процеси за використанням пам’яті:
  
  M
- Тепер, коли інформація про пам’ять відображається в індикаторах виконання, а процеси, відсортовані за використанням пам’яті, збережіть ці конфігурації, щоб отримати їх за замовчуванням наступного разу, коли ви використовуєте top:
  
  W
- У якому файлі зберігаються налаштування конфігурації top? Де він розташований? Як перевірити його наявність?
  
  Файл має назву ~/.config/procps/toprc і знаходиться в домашньому каталозі користувача (~). Оскільки це прихований файл (він знаходиться в каталозі, ім’я якого починається з крапки), ми можемо перевірити його існування за допомогою ls -a (перелік усіх файлів). Цей файл можна створити, натиснувши kbd:[Shift+W] в top.
Дізнайтеся про команду exec у оболонці Bash. Спробуйте продемонструвати її функціональність, запустивши сеанс Bash, знайшовши процес Bash за допомогою ps, потім запустіть exec /bin/sh і знову знайдіть процес з тим самим PID.

exec замінює процес іншою командою. У наступному прикладі ми бачимо, що процес Bash замінений на /bin/sh (замість того, щоб /bin/sh став дочірнім процесом):
```
$ echo $$
19877
$ ps auxf | grep 19877 | head -1
carol  19877  0.0  0.0   7448  3984 pts/25   Ss   21:17   0:00  \_ bash
$ exec /bin/sh
sh-5.0$ ps auxf | grep 19877 | head -1
carol  19877  0.0  0.0   7448  3896 pts/25   Ss   21:17   0:00  \_ /bin/sh
```
Виконайте ці кроки, щоб дослідити події ядра та динамічне керування пристроями udev:
- Вставте USB-накопичувач до включеного комп’ютера. Запустіть dmesg і зверніть увагу на останні рядки. Яка інформація в останньому рядку?
  
  Ви повинні отримати щось на зразок [ 1967.700468] sd 6:0:0:0: [sdb] Attached SCSI removable disk.
- Пам’ятаючи про результат попередньої команди, запустіть ls /dev/sd* і переконайтеся, що ваш USB-накопичувач з’являється у списку. Що ми бачимо у вихідних даних?
  
  Залежно від кількості пристроїв, підключених до вашої системи, ви повинні отримати щось на кшталт /dev/sda /dev/sda1 /dev/sdb /dev/sdb1 /dev/sdb2. У нашому випадку ми знаходимо наш USB-накопичувач (/dev/sdb) і два його розділи (/dev/sdb1 і /dev/sdb2).
- Тепер вийміть USB-накопичувач і знову запустіть dmesg. Яка інформація в останньому рядку?
  
  Ви повинні отримати щось на зразок [ 2458.881695] usb 1-9: USB disconnect, device number 6.
- Знову запустіть ls /dev/sd* і переконайтеся, що ваш пристрій зник зі списку. Що ми бачимо у вихідних даних?
  
  У нашому випадку /dev/sda /dev/sda1.