Praktičan, korak‑po‑korak vodič za rešavanje problema na Linux serveru

Article Image

Rešavanje problema na Linux serveru: metodologija i osnovni alati

Ovaj praktičan vodič pokriva ključne korake za rešavanje problema na Linux serveru, od sistematske dijagnostike do rada sa logovima i upotrebe osnovnih komandi. Cilj je da pomogne administratorima i inženjerima svih nivoa da brzo identifikuju uzrok kvara (SSH, mreža, prostor na disku, systemd servisi, performanse) i bezbedno sprovedu korektivne radnje. Pristup će kombinovati metodologiju, praktične komande i bezbednosne preporuke.

Kako pristupiti dijagnostici: jasna metodologija korak‑po‑korak

Pre nego što počne sa bilo kakvom intervencijom, najbolje je pratiti ponovljivi proces. Metodologija pomaže da se izbegnu nepotrebne promene i da se sačuva stabilnost produkcionih sistema.

  1. Prikupljanje podataka: Koji servis ne radi, kada je problem primеćen, ima li uticaja na korisnike?
  2. Reprodukcija i opseg: Da li je problem lokalizovan na jednom hostu, podmreži ili celom klasteru?
  3. Radi se minimalna intervencija: Napraviti sigurnosnu kopiju konfiguracija pre promena.
  4. Rad sa logovima i alatima za praćenje: Zabeležiti relevantne logove pre i posle promena.
  5. Plan za povratak: Imati korake za vraćanje sistema u prethodno stanje ako intervencija napravi grešku.

Ovaj proces treba primenjivati svaki put: najpre prikupljanje informacija, zatim analiza i tek na kraju ispravka. Time se smanjuje rizik od pogoršanja problema.

Koje informacije odmah prikupiti

  • ID hosta i verzija distribucije: cat /etc/os-release (bezbedno za pokretanje, nema potrebe za root privilegijama). Objašnjenje: pokazuje distribuciju i verziju sistema.
  • Trenutno opterećenje i memorija: uptime, free -m (sudo nije potreban). Objašnjenje: pomaže da se vidi da li su opterećenje ili OOM odgovorni za prekid.
  • Slobodan disk: df -h (bez sudo). Objašnjenje: proverava dostupni prostor po mount tački.
  • Aktivni servisi i njihovo stanje (systemd): sudo systemctl status ime_servisa. Objašnjenje: zahteva sudo; pokazuje da li je servis aktivan, greške i poslednje logove.
  • Recentni sistemski logovi: sudo journalctl -u ime_servisa -n 200 --no-pager. Objašnjenje: prikazuje poslednjih 200 zapisa za dati systemd servis; zahteva sudo.

Osnovni alati za rad sa logovima i praćenje stanja

Rad sa logovima i komandama za brzo očitavanje stanja sistema je neophodan za rešavanje problema na Linux serveru. Sledeći alati su univerzalno korisni na većini distribucija (Ubuntu, Debian, CentOS, RHEL).

  • journalctl — centralni sistemski log (systemd distribucije). Primer:
    sudo journalctl -b -p err --no-pager
    

    Objašnjenje: prikazuje greške od poslednjeg boot-a; zahteva sudo.

  • tail — praćenje fajlova u realnom vremenu:
    sudo tail -n 200 /var/log/auth.log
    

    Objašnjenje: prikazuje poslednjih 200 linija fajla auth.log; često koristan za SSH probleme. Upozorenje: ne briše fajlove.

  • dmesg — kernel poruke vezane za hardver:
    sudo dmesg | less
    

    Objašnjenje: pomaže u otkrivanju problema sa diskovima, mrežnim karticama ili drajverima.

Sledeći deo vodiča detaljno će pokazati konkretne primere za rešavanje specifičnih kvarova (SSH pristup, mreža, disk, systemd servisi i performanse) sa komandama, primerima izlaza i koracima za ispravljanje grešaka.

Problem sa SSH pristupom: brza dijagnostika i konkretni koraci

Prvi korak je utvrditi da li je problem na strani servera ili klijenta. Koristite dijagnostičke izlaze sa klijenta i logove na serveru.

– Na klijentu pokrenite verbose konekciju:

ssh -vvv user@server.example.com

Objašnjenje: vidi tačan trenutak greške (DNS, TCP, TLS/SSH handshake, autentikacija).

– Na serveru proverite da li je sshd pokrenut i sluša port 22:

sudo systemctl status sshd
sudo ss -tnlp | grep :22

– Pregledajte autentifikacione logove:

sudo journalctl -u sshd -n 200 --no-pager
sudo tail -n 200 /var/log/auth.log

Obratite pažnju na poruke o odbijenim ključevima, pogrešnim dozvolama ili blokiranju (npr. fail2ban).

– Proverite dozvole i vlasništvo ključeva:

ls -la /home/username/.ssh
chmod 700 /home/username/.ssh
chmod 600 /home/username/.ssh/authorized_keys
chown -R username:username /home/username/.ssh

Napomena: pogrešne dozvole često uzrokuju odbacivanje ključeva.

– Firewall i SELinux:

sudo ufw status
sudo iptables -L -n
sudo semanage port -l | grep ssh   # ako je SELinux aktivan

Ako SELinux blokira, koristeći audit logove i restorecon može pomoći:

sudo ausearch -m avc -ts recent
sudo restorecon -Rv /home/username/.ssh

– Hitne popravke: ako je server nedostupan zbog loše konfiguracije (/etc/ssh/sshd_config), vratite bekap ili testirajte novu konfiguraciju bez gašenja:

sudo sshd -t && sudo systemctl restart sshd

Ako restart ne uspe, vratite sačuvani fajl ili koristite konzolu hosting provajdera.

Mrežne konekcije: postupna proverа i alati za izolaciju problema

Krenite od lokalne mrežne konfiguracije ka udaljenim tačkama da biste identifikovali gde se prekid dešava.

– Osnovna dijagnostika:

ip a
ip route
cat /etc/resolv.conf

Proverite da li su interfejsi i rute ispravni i da li postoji DNS rezolucija.

– Test konekcije:

ping -c 4 8.8.8.8
ping -c 4 server.example.com
traceroute -n server.example.com

Razlikujte problem sa IP slojem (ping prema IP radi, DNS ne radi) od problema sa aplikativnim portom.

– Port i servis:

ss -tunlp | grep :80
sudo nmap -p 22,80,443 server.example.com

Ako port nije otvoren, proverite lokalni firewall ili servis.

– Složenija izolacija:

sudo tcpdump -i eth0 host 10.0.0.5 and port 443 -n
sudo ethtool eth0

Tcpdump pokazuje dolazni/odlazni saobraćaj; ethtool otkriva greške na linku ( CRC, collisions, speed/duplex ).

– MTU i ARP problemi:

ip link set dev eth0 mtu 1400
ip neigh show

Smanjenje MTU ponekad rešava probleme sa fragmentacijom (VPN, tuneli). ARP tabele pokazuju da li je neighbor reachable.

Nedostatak prostora na disku: kako pronaći uzrok i osloboditi prostor bez rizika

Pun disk može paralizovati servise i izazvati nepredvidivo ponašanje. Prvo identifikujte kritične mount tačke.

– Pregled zauzeća:

df -h
du -sh /var/* | sort -h
sudo du -xh / | sort -rh | head -n 30

du pronalazi velike direktorijume; počnite sa /var, /home i /tmp.

– Log fajlovi i rotacija:

sudo ls -lh /var/log
sudo journalctl --disk-usage
sudo journalctl --vacuum-size=500M
sudo logrotate -f /etc/logrotate.conf

Očistite stare journald zapise ili podesite rotaciju umesto brisanja važnih logova.

– Otkriveni “deleted but open” fajlovi:

sudo lsof +L1

Fajlovi koji su obrisani, ali drže se otvorenim descriptor-om i dalje zauzimaju prostor — restart procesa koji ih drži ili graceful restart servisa će ih osloboditi.

– Privremena oslobađanja:
– apt-get clean / yum clean all
– proveriti i obrisati nepotrebne snapshots (LVM, btrfs, ZFS)
– premestiti velike arhive na drugi disk ili mrežni share
– ne brišite sistemske fajlove bez bekapa — uvek napravite kopiju konfiguracija pre velikih promena.

Neuspele systemd usluge i kako ih oporaviti

Kada se servis ne pokreće ili često pada, pridržavajte se sistematskog pristupa: proverite stanje servisa, pročitajte logove, potvrdite jedinicu (unit), i proverite zavisnosti i resurse koje servis zahteva.

  • Provera osnovnog stanja i poslednjih poruka: pokrenite systemctl status ime_servisa i journalctl -u ime_servisa -n 200 da biste videli greške i stack trace.
  • Validacija konfiguracije: ako ste menjali unit fajlove, koristite systemd-analyze verify putanja_do_unit_fajla, potom systemctl daemon-reload i testirajte start bez restartovanja drugih servisa.
  • Zavisnosti i aktivacija: proverite systemctl list-dependencies ime_servisa i potražite socket-activation ili zahtevane target-e koji mogu blokirati start.
  • Privilegije i okruženje: proverite koje korisničke privilegije servis koristi, environment fajlove, i dozvole na binarnim fajlovima; promena korisnika ili prava može sprečiti start.
  • Ograničenja i resursi: proverite LimitNOFILE, LimitNPROC i cgroup ograničenja u unit fajlu; ako servis ne može da otvori fajlove ili kreira procese, podesite odgovarajuće limite i ponovo pokrenite servis.
  • Reset i clean-up: za servis koji je u failed stanju koristite systemctl reset-failed ime_servisa, proverite postoji li race condition pri startu i, ako je potrebno, omogućite Restart opciju u unit fajlu sa primerenim slep parametrima (Restart=on-failure, RestartSec=).
  • Bezbednosne politike: ako je SELinux ili AppArmor aktivan, proverite audit logove (ausearch/audit.log) i prilagodite booleans ili pravila pre nego što menjate servisne fajlove.

Problemi sa performansama: identifikacija i kratkoročne kontra mere

Problemi sa performansama zahtevaju brzu kategorizaciju: CPU, memorija, IO ili mreža. Fokusirajte se na prvo otkrivanje uzroka, zatim na kratkoročne mere za stabilizaciju i dugoročno rešenje.

  • Brza dijagnostika: proverite load average i top ili ps kako biste videli najzahtevnije procese; proverite swap i memoriju (free), i IO korišćenje (iostat ili vmstat).
  • CPU usko grlo: pronađite procese sa visokim %CPU, proverite da li je problem korisničkog prostora ili kernel-a; za kratko, smanjite broj paralelnih poslova, podesite nice/ionice ili restartujte problematične procese.
  • Memorija i OOM: ako je aktiviran OOM killer, potražite dmesg ili journalctl -k; povećajte dostupnu memoriju, smanjite cache ili podesite vm.swappiness, ali prvo identifikujte curenje memorije u aplikaciji.
  • IO latencija: upotrebite iostat, iotop ili atop da otkrijete uređaje sa visokim čekanjem; privremeno smanjite opterećenje pisanja, premestite zahtevne IO operacije na drugi disk ili throttling pomoću cgroups.
  • Mrežni uslovi: za velike broj konekcija ili packet loss proverite ss/netstat, conntrack stanje i latenciju sa ping/traceroute; povećajte net.core.somaxconn i druge relevantne sysctl vrednosti ako je potrebno.
  • Praćenje i metrika: postavite kratkoročne alarme za CPU, IO i slobodnu memoriju; nakon hitnog rešenja, analizirajte metrike da biste predupredili ponavljanje problema.

Održavanje i sledeći koraci

Dosledna metodologija, zapisivanje postupaka i automatsko praćenje su ključni za smanjenje učestalosti i trajanja incidenata. Vežbajte popravke u testnom okruženju, dokumentujte runbook-ove za uobičajene kvarove, i posle svake intervencije obavite kratak post‑mortem kako biste iz korena otklonili uzroke i unapredili procese. Na taj način ćete graditi otpornost sistema i veštine tima, što na kraju štedi vreme i smanjuje rizik u produkciji.