(Filip Vervloesem) Troubleshooting via logfiles, Waar begin je te zoeken?

Je kan pas problemen oplossen op je systeem als je over voldoende informatie beschikt. Voor troubleshooting zijn logfiles dan ook cruciaal. Helaas staan die wel eens verspreid over verschillende locaties. Waar begin je dan best te zoeken?

In principe staan alle logfiles op één centrale locatie, namelijk in de directory /var/log. Let wel op: we zeggen ‘in principe’, want op een moderne Linux-distro moet je soms ook elders zoeken. Heel wat programma’s gebruiken traditioneel de syslog-daemon om logberichten weg te schrijven. Afhankelijk van de syslog-configuratie (/etc/syslog.conf) worden die berichten opgesplitst in verschillende logfiles. Op een Debian/Ubuntu-systeem vind je bijvoorbeeld berichten in verband met authenticatie in /var/log/auth.log en algemene berichten in /var/log/syslog. Red Hat-gebaseerde systemen gebruiken dan weer /var/log/secure en /var/log/messages voor diezelfde berichten. Tegenwoordig is syslog vervangen door rsyslog, maar het principe blijft hetzelfde. Al die logs zijn platte tekstbestanden, die je bekijkt en doorzoekt met tools zoals less en grep.

systemd

Systemd bevat een eigen daemon ter vervanging van (r)syslog, namelijk journald. Die schrijft de logberichten niet zomaar weg in platte tekstbestanden, maar in een binair formaat onder /run/log/journal. Afhankelijk van de configuratie, vind je daarin enkel de berichten sinds de laatste boot of ook oudere berichten. Je hebt in elk geval een speciale tool nodig om de logs te kunnen lezen, namelijk journalctl. Dat lijkt op het eerste zicht minder handig, maar journalctl bevat verschillende opties om de output te filteren. Zo hoef je niet steeds door alle berichten te scrollen, maar zie je enkel de subset waarin je op dat moment geïnteresseerd bent. Je kan de berichten beperken tot een bepaald programma:

* -u <service>: de berichten van één specifieke service, bijvoorbeeld ssh

* /pad/naar/binary: de berichten van een bepaalde binary, bijvoorbeeld /usr/sbin/tor

 

Of tot een bepaald tijdsstip:

* -S "YYYY-MM-DD HH:MM:SS" -U "YYYY-MM-DD HH:MM:SS": de berichten tussen twee tijdsstippen

* -S -1h30m: de berichten van de laatste anderhalf uur

 

Combineer één van de eerste twee opties met één van de laatste twee om erg gericht te zoeken.

 

Applicatielogs

Sommige applicaties loggen zoveel data dat het onoverzichtelijk wordt om via syslog of systemd te loggen. Vaak gebruiken die een subdirectory onder /var/log met daarin meerdere logbestanden. Een duidelijk voorbeeld daarvan is Samba. Dat bestaat uit verschillende daemons (smbd, nmbd en winbindd) met elk een eigen logfile. Bovendien maakt Samba extra logfiles aan voor elke client die verbonden is. Onder /var/log/samba vind je dus al gauw een tiental logfiles met nuttige troubleshooting informatie. Applicatielogs hoeven trouwens niet onder /var/log te staan. Dat gebeurt vooral bij software die niet via een package manager is geïnstalleerd. Is een bepaald programma manueel geïnstalleerd onder /opt/<programma>? Veel kans dat je de logs dan vindt onder /opt/<programma>/<file>.log of /opt/<programma>/logs.

 

Logs zoeken

Heb je de software zelf geïnstalleerd en geconfigureerd, dan weet je allicht waar de logs terechtkomen. Beheer je een systeem dat je niet zelf hebt geconfigureerd? Dan is het soms wat lastiger om de precieze locatie uit te zoeken van bepaalde applicatielogs. Een handige truc is dan om even na te kijken welke bestanden het programma allemaal geopend heeft. Zo zie je meteen of het logs wegschrijft op niet-standaard locaties. Een eenvoudig voorbeeld voor een proces dat met de naam “tor” begint:

$ lsof -c tor | grep -i log

Of voor een proces waarvan je het PID reeds hebt opgezocht:

$ lsof -p 796 | grep -i log