Pāriet uz saturu

Sīkdatņu iestatījumi

Izvēlieties, kāda veida sīkdatnes atļaujat. Savu izvēli varat jebkurā laikā mainīt sadaļā Sīkdatņu iestatījumi katras lapas apakšā. Privātuma politika

Nepieciešamās

Vienmēr ieslēgtas

Vajadzīgas, lai pieteiktos, saglabātu grozu un atcerētos Jūsu izvēles. Tās vienmēr ir ieslēgtas.

Kuras sīkdatnes?
  • weboke_sessie, weboke_klant, weboke_remember: Jūsu sesija un pieteikšanās saglabāšana
  • weboke_basket: Jūsu grozs
  • wkBtwIncl: cenu rādīšana ar PVN vai bez PVN
  • wok_cookies: Jūsu sīkdatņu izvēle, 12 mēneši

Mēra, kura reklāma noved pie apmeklējuma vai pasūtījuma, lai mēs nemaksātu par reklāmām, kas neko nedod.

Kuras sīkdatnes?
  • Google Ads ar Google Tag Manager (_gcl_au, _gcl_aw), līdz 90 dienām
  • OpenAI Ads, reklāmas ChatGPT
  • wok_aff: caur kuru partneri nonācāt pie mums (partneru programma), 60 dienas

4,6

Valsts un valoda

Katrai valstij ir sava vietne ar attiecīgās valsts cenām un PVN.

Skatīt

Žurnālu lasīšana ar journalctl

6. modulis: Pakalpojumi un žurnāli · Lasīšanas laiks: 11 min.

Mācīšanās mērķis: Pēc šīs nodarbības Jūs ar journalctl varēsiet mērķtiecīgi meklēt sava servera žurnālos (pēc pakalpojuma, prioritātes un laika), zināsiet, kur atrodas citi žurnālfaili, un novērsīsiet situāciju, kad žurnāli aizpilda Jūsu disku.

Pamatjēdzieni: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, prioritāte (err, warning, info), pastāvīga glabāšana, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Žurnāls kā pirmais liecinieks

Ja kaut kas Jūsu serverī nedarbojas, iemesls gandrīz vienmēr ir ierakstīts žurnālā. Vietne, kas rāda kļūdas lapu, pakalpojums, kas nepalaižas, rezerves kopija, kas šonakt netika izveidota: serveris to visu ir pierakstījis. Labs administrators vispirms ieskatās žurnālā un tikai pēc tam sāk kaut ko mainīt.

Mūsdienu Linux serveros journald (systemd daļa) apkopo kodola, paša systemd un visu pakalpojumu ziņojumus vienā žurnālā: journal. To lasa ar journalctl.

Lai varētu izlasīt visu, Jums jābūt grupā adm vai systemd-journal, vai arī jāizmanto sudo. Bez šīm tiesībām Jūs redzat tikai savus ziņojumus.

Kur tas glabājas? Pastāvīgi vai īslaicīgi

journald glabā žurnālu vienā no divām vietām:

  • mapē /var/log/journal/: pastāvīgi, žurnāli saglabājas arī pēc restartēšanas;
  • mapē /run/log/journal/: īslaicīgi, atmiņā, pēc restartēšanas tie pazūd.

Noklusējuma iestatījums (Storage=auto failā /etc/systemd/journald.conf) izvēlas pastāvīgu glabāšanu, ja mape /var/log/journal/ eksistē. Debian sistēmā systemd pakotne šo mapi izveido jau kopš Debian 11, un arī Ubuntu tā ir. Pārbaudiet to:

anna@web1:~$ ls -d /var/log/journal
/var/log/journal
anna@web1:~$ journalctl --list-boots | tail -n 3
 -2 3c1f... Sun 2026-11-01 04:30:12 CET Sun 2026-11-08 04:30:01 CET
 -1 9ab7... Sun 2026-11-08 04:30:40 CET Mon 2026-11-09 08:12:05 CET
  0 e41d... Mon 2026-11-09 08:12:30 CET Mon 2026-11-09 11:40:17 CET

Ja redzat tikai vienu palaišanas reizi, lai gan serveris jau ir restartēts, Jūsu žurnāli ir īslaicīgi. Izveidojiet mapi (sudo mkdir -p /var/log/journal un sudo systemd-tmpfiles --create --prefix /var/log/journal) un restartējiet journald. Tas ir svarīgi: pēc avārijas Jūs gribat zināt tieši to, kas notika pirms restartēšanas.

Kopš Debian 12 Debian pēc noklusējuma vairs neinstalē rsyslog. Šī programma agrāk rakstīja teksta failus, piemēram, /var/log/syslog un /var/log/auth.log. Jaunā Debian serverī tādu failu tātad nav; viss atrodas žurnālā. Ubuntu rsyslog joprojām ir. Pamācības, kurās teikts "skatieties /var/log/auth.log", Debian sistēmā varat pārtulkot uz journalctl -u ssh.

Meklēšana: filtri, kurus tiešām izmantosiet

Bez filtra journalctl parāda visu, sākot ar vecāko ierakstu. Reti kad tas ir tas, kas Jums vajadzīgs. Svarīgākie filtri, kurus var apvienot:

FiltrsPiemērsKo dara
-u <unit>journalctl -u nginxtikai šis pakalpojums
-p <prioriteit>journalctl -p errtikai kļūdas un nopietnāki ziņojumi
--since, --until--since "2026-11-09 03:00" --until "04:00"laika posms; arī today, yesterday, "1 hour ago"
-bjournalctl -b, journalctl -b -1kopš šīs palaišanas vai iepriekšējās
-fjournalctl -u nginx -fsekot līdzi reāllaikā (kā tail -f), apturēt ar Ctrl+C
-ejournalctl -u ssh -epāriet uz beigām
-njournalctl -u ssh -n 50pēdējās 50 rindas
-kjournalctl -ktikai kodola ziņojumi
--no-pagerbez lapošanas, ērti kopā ar grep

Prioritātes ir no 0 (emerg) līdz 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Ar -p err Jūs saņemat err un visu, kas ir nopietnāks. -p warning parāda arī brīdinājumus.

Tipisks meklēšanas ceļš. Jūsu vietne kopš šī rīta rāda kļūdu 502:

anna@web1:~$ systemctl status php8.4-fpm
× php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager
     Active: failed (Result: exit-code) since Mon 2026-11-09 07:02:11 CET; 4h ago
...
anna@web1:~$ sudo journalctl -u php8.4-fpm --since today -p warning --no-pager
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: [/etc/php/8.4/fpm/pool.d/www.conf:42] unknown entry 'pm.max_children '
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: FPM initialization failed
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Failed with result 'exit-code'.

Cēlonis ir ierakstīts burtiski: drukas kļūda konfigurācijas faila 42. rindā. Statuss 78 (CONFIG) apstiprina, ka tā ir konfigurācijas kļūda. Nekas nav jāmin.

Divi padomi lasīšanai:

  • Lasiet no augšas uz leju un meklējiet pirmo kļūdu. Viena kļūda bieži izraisa veselu virkni sekojošu ziņojumu. Pirmā parasti ir cēlonis.
  • Pievērsiet uzmanību laikam. Kas mainījās ap šo brīdi? Automātisks atjauninājums (nodarbība 4.2: /var/log/unattended-upgrades/), Jūsu veiktas izmaiņas, restartēšana?

Citi žurnālfaili

Ne viss atrodas žurnālā. Daudzas programmas raksta arī (vai tikai) savus failus mapē /var/log/:

Fails vai mapeKas tajā ir
/var/log/nginx/access.log un error.logkatrs nginx pieprasījums un katra kļūda
/var/log/apt/history.logko apt instalēja un kad
/var/log/unattended-upgrades/automātiskie atjauninājumi (nodarbība 4.2)
/var/log/fail2ban.logbloķēšanas (nodarbība 5.3)
/var/log/mysql/ vai žurnālsMariaDB/MySQL, atkarībā no iestatījuma

Lielus teksta failus lasiet ar less (meklēšana ar /), beigas ar tail -n 50, reāllaikā ar tail -f un filtrējiet ar grep:

anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5

Docker konteineru žurnāli neatrodas mapē /var/log, bet pie paša Docker: docker compose logs (nodarbība 9.3).

Žurnāli nedrīkst aizpildīt Jūsu disku

Pilns disks ir viens no biežākajiem iemesliem, kāpēc serveris "pēkšņi" vairs nedarbojas: datubāzes apstājas, atjauninājumi neizdodas, dažreiz pat vairs nevar pieteikties. Bieži vainīgi ir žurnāli.

Žurnāls (journal) ierobežo sevi pats. Pēc noklusējuma tas izmanto ne vairāk kā 10% no failu sistēmas, ar maksimumu 4 GB (SystemMaxUse=). Cik daudz tas izmanto pašlaik un kā to iztīrīt:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # vecāki par 30 dienām tiek dzēsti
anna@web1:~$ sudo journalctl --vacuum-size=500M    # līdz 500 MB

Ja vēlaties noteiktu robežu, ierakstiet to drop-in failā /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

un restartējiet journald ar sudo systemctl restart systemd-journald.

Teksta failus mapē /var/log uztur logrotate: katru dienu vai nedēļu fails tiek pārdēvēts (error.log.1), vecākās versijas tiek saspiestas (.gz), un vecākās tiek izdzēstas. Noteikumi katrai programmai atrodas mapē /etc/logrotate.d/. Distribūcijas pakotnes ienes savus noteikumus. Ja Jūsu pašu programma vai skripts raksta savā žurnālfailā, izveidojiet noteikumu paši, citādi fails augs bezgalīgi.

Kā atrast, kas aizņem vietu:

anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5

Žurnāli un privātums

Žurnālos ir IP adreses, lietotājvārdi un dažreiz e-pasta adreses: tie ir personas dati. Neglabājiet tos ilgāk, nekā nepieciešams (mazam serverim ierasts ir no dažām nedēļām līdz dažiem mēnešiem), neatstājiet tos publiski pieejamus (mape /logs Jūsu webroot ir labi zināma kļūda) un nekopējiet tos bez apdoma uz citu pakalpojumu sniedzēju servisiem.

AlmaLinux un Rocky Linux sistēmās

journalctl darbojas tāpat. Tur rsyslog joprojām ir ieslēgts pēc noklusējuma, ar tādiem failiem kā /var/log/messages un /var/log/secure (auth.log analogs). SELinux ziņojumi atrodas /var/log/audit/audit.log; ausearch -m avc -ts recent parāda nesenos atteikumus.

Kopsavilkums

  • journald apkopo visus ziņojumus žurnālā; lasiet to ar journalctl, filtrējot pēc pakalpojuma (-u), prioritātes (-p), laika (--since) un palaišanas reizes (-b).
  • Pārbaudiet, vai žurnāls ir pastāvīgs (/var/log/journal eksistē), citādi pēc restartēšanas Jūsu žurnāli pazudīs.
  • Debian 12 un jaunākām versijām pēc noklusējuma nav rsyslog, un tātad nav arī /var/log/auth.log un /var/log/syslog; viss atrodas žurnālā.
  • Meklējiet pirmo kļūdu un skatieties, kas mainījās ap šo brīdi.
  • Sekojiet apjomam: žurnāls ierobežo sevi pats (--disk-usage, --vacuum-*), teksta failus pārvalda logrotate.

Tests (quiz)

1. Kura komanda parāda tikai šodienas nginx kļūdas?



2. Jūsu serveris šonakt tika restartēts pēc avārijas. journalctl -b -1 izvada "Specifying boot ID or boot offset has no effect, no persistent journal was found". Ko tas nozīmē?



3. Pamācībā teikts, ka neveiksmīgas SSH pieteikšanās var atrast /var/log/auth.log, bet Jūsu jaunajā Debian 13 serverī šāda faila nav. Kur meklēt?



4. Žurnālā ir divdesmit kļūdu ziņojumi pēc kārtas. Ar ko sākt?



5. Jūsu disks ir pilns, un journalctl --disk-usage rāda 400 MB. Kāds ir labākais nākamais solis?



Uzdevums

Uzdevums Z6.2: Avarējoša pakalpojuma analīze. Piemēra failā journal-crash-1.txt ir systemctl status un journalctl izvade no pakalpojuma, kas atkārtoti palaižas un tad padodas. Atbildiet: kā sauc pakalpojumu, cik reizes systemd mēģināja to palaist, ar kādu izejas kodu tas apstājās, kāds ir cēlonis saskaņā ar pirmo kļūdas ziņojumu, un cikos systemd padevās? Programma salīdzina Jūsu atbildes ar fiksētu atslēgu. Pēc tam pārbaudiet savā serverī, vai journalctl -p err -b rāda kļūdas un vai Jūsu žurnāls ir pastāvīgs.

Uzdevums Z6.2: Avarējoša pakalpojuma analīze

Fails šim uzdevumam: journal-crash-1.txt







To, ko ievadāt, un to, ko atrodam, mēs nesaglabājam. Jūsu pārlūkprogramma atceras Jūsu atbildes un to, vai esat izpildījuši uzdevumu. Ja esat pieteikušies, sadaļā Mani kursi saglabājam tikai to, ka uzdevums bija (gandrīz) pareizs; tur to varat arī dzēst.

Vairāk lasīt

Lūdzu, uzgaidiet…

Iestatiet savus domēnus

Katram domēnam norādiet vārdu serverus, piesaisti hostingam un to, kurš būs turētājs.

Ielādē Jūsu domēnus…