Vodič kroz rešavanje problema na Linux serveru: 5 kritičnih scenarija — deo 1

Article Image

Prvi koraci pri rešavanju problema na Linux serveru — fokus: web server nije dostupan

Ovaj vodič daje sažete, praktične korake za dijagnostiku i rešavanje najčešćih problema na Linux serveru. Cilj je da administratori i DevOps brzo utvrde uzrok i primene privremeno ili trajno rešenje. U ovom delu fokus je na scenariju kada web server nije dostupan, sa komandama i smernicama za bezbedan rad.

Brza provera stanja i očekivani rezultati pre daljeg rada

Pre bilo kakvih izmena potvrdite šta tačno ne radi: servis, port, konfiguracija ili mreža. Početna provera treba da da listu potencijalnih uzroka (npr. servis down, port zatvoren, greška u konfiguraciji, resursi zagušeni) i sledeće korake.

  • Sve naredbe koje menjaju konfiguraciju ili restartuju servise zahtevaju sudo/root — po potrebi dodajte sudo.
  • Pre restartovanja obavestite korisnike i, gde je moguće, radite van radnog vremena.

Osnovna dijagnostika: proveriti servis i port

Proverite status servisa i da li sluša očekivane portove (80/443):

sudo systemctl status nginx
sudo systemctl status apache2   # ili httpd
sudo ss -tulwn | grep -E ':80|:443'

Ako servis nije aktivan ili ne sluša, to ukazuje na servisni ili konfiguracioni problem. Zabeležite greške iz izlaza pre narednih koraka.

Brzo privremeno rešenje: restart i test konfiguracije

Pre restartovanja uvek testirajte konfiguraciju:

sudo nginx -t
sudo apachectl configtest
sudo systemctl restart nginx
sudo systemctl restart apache2

Restart često vraća dostupnost, ali zabeležite greške iz testova i logova kako biste trajno otklonili uzrok.

Analiza logova — kako brzo pronaći uzrok greške

Logovi najčešće otkrivaju uzrok (500/502/504, permission denied, segfault, OOM). Koristite journalctl i direktne log fajlove:

sudo journalctl -u nginx -S "1 hour ago" --no-pager
sudo tail -n 200 /var/log/nginx/error.log
sudo grep -i "permission denied|segfault|proxy|502|504" /var/log/nginx/error.log

Obratite pažnju na poruke o OOM, probleme sa backendom (npr. PHP-FPM, gunicorn) i sintaksne greške u konfiguraciji.

sudo dmesg | tail -n 50
sudo systemctl status php7.4-fpm

Ako je backend uzrok, restartajte samo taj servis dok ne sprovedete trajno rešenje:

sudo systemctl restart php7.4-fpm
sudo systemctl restart gunicorn.service

Dozvole fajlova, SELinux/AppArmor i ostale sigurnosne blokade

Proverite vlasništvo i permisije direktorijuma sajta i ispravite prema korisniku web servera (npr. www-data ili apache):

ls -ld /var/www/html
sudo chown -R www-data:www-data /var/www/html
sudo find /var/www/html -type d -exec chmod 750 {} ;
sudo find /var/www/html -type f -exec chmod 640 {} ;

Za SELinux privremeno testirajte isključivanje (dijagnostika) i zatim podesite kontekste:

getenforce
sudo setenforce 0            # samo za test
sudo restorecon -Rv /var/www/html
sudo chcon -R -t httpd_sys_content_t /var/www/html

Za AppArmor proverite profile i stavite u complain mod radi testiranja:

sudo aa-status
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

Trajna rešenja: systemd automatsko restartovanje, monitoring i skaliranje

Da biste smanjili downtime uvedite automatski restart, monitoring i plan skaliranja:

sudo mkdir -p /etc/systemd/system/nginx.service.d
echo -e "[Service]
Restart=on-failure
RestartSec=5s" | sudo tee /etc/systemd/system/nginx.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart nginx
  • Monitoring: jednostavno (monit/healthcheck skripta) ili robustno (Prometheus + Alertmanager, Datadog).
  • Skaliranje: horizontalno (više instanci + load balancer) ili vertikalno; koristite health checks da izbacujete loše instance.

Baza podataka je spora ili ne radi

Brza dijagnostika

Proverite status servisa i aktivne konekcije:

sudo systemctl status mysql    # ili mariadb/postgresql
mysql -e "SHOW PROCESSLISTG"
sudo -u postgres psql -c "SELECT pid,state,query FROM pg_stat_activity WHERE state  'idle';"

Privremeno rešenje

  • Restartujte servis kontrolisano: sudo systemctl restart mysql ili sudo systemctl restart postgresql.
  • Prekinite dugotrajne upite (KILL ili pg_terminate_backend).
  • Privremeno povećajte swap ili resurse VM-a ako je potrebno.

Trajno rešenje

  • Uključite slow query log i analizirajte najsporije upite; koristite EXPLAIN/ANALYZE.
  • Koristite connection pooling (PgBouncer, ProxySQL) i podesite parametre baza prema opterećenju.
  • Postavite monitoring za latenciju i broj konekcija; planirajte replikaciju/skladiranje.

Disk particija je puna

Brza dijagnostika

Proverite zauzeće i velike fajlove:

df -h
du -xh / | sort -rh | head -20
sudo find / -xdev -type f -size +100M -exec ls -lh {} ;
sudo lsof | grep deleted

Privremeno rešenje

  • Očistite keš paketa: sudo apt-get clean ili sudo yum clean all.
  • Skraćivanje velikih logova: sudo truncate -s 0 /var/log/large-log-file ili premestite arhive.
  • Restartujte servis koji drži obrisane fajlove ili reboot ako je bezbedno.

Trajno rešenje

  • Podesite logrotate i ograničenja journalctl: sudo journalctl --vacuum-size=100M.
  • Kreirajte izdvojene particije za /var ili koristite LVM/novi disk za skalabilnost.
  • Uvedite monitoring slobodnog prostora i alerting pre nego što particija postane puna.

Server se ne diže (boot)

Brza dijagnostika

Pristupite konzoli ili serialu, pregledajte poslednji boot i failed servise:

sudo journalctl -b -1 --no-pager
systemctl --failed
sudo blkid
cat /etc/fstab

Privremeno rešenje

  • Bootujte u recovery/rescue režim ili izaberite prethodni kernel preko GRUB-a.
  • Ako root particija nema prostora, pokrenite sa live medija, mount-ujte i očistite prostor.
  • Za oštećen GRUB koristite live medijum, chroot i reinstalirajte GRUB: grub-install /dev/sda.

Trajno rešenje

  • Automatizujte backup konfiguracija (fstab, grub.cfg) i testirajte kernel update u stagingu.
  • Monitorišite SMART i zdravlje diska; dokumentujte recovery procedure.
  • Imati runbook za boot recovery sa pristupom konzoli i ključnim komandama.

Mrežni prekidi i probleme sa konektivnošću

Brza dijagnostika

Proverite interfejs, rutu i dostupnost gateway-a/externih adresa:

ip a
ip route
ping -c 4 
ping -c 4 8.8.8.8
traceroute    # ili mtr
sudo journalctl -u NetworkManager

Privremeno rešenje

  • Restart mrežnog servisa: sudo systemctl restart NetworkManager (pažljivo kod udaljenih servera).
  • Prebacite saobraćaj na rezervni interfejs ili failover vezu ako je fizički problem.
  • Smanjite MTU ili onemogućite offloading preko ethtool ako je potrebno za dijagnostiku.

Trajno rešenje

  • Implementirajte redundantne veze (bonding/teaming), keepalived ili BGP za multi-homing.
  • Automatizujte healthcheck i alerting za latenciju i packet loss; održavajte drajvere i firmware NIC-a.
  • Dokumentujte mrežnu topologiju i failover procedure.

Završne napomene i dalji koraci

Rešavanje problema na Linux serveru zahteva kombinaciju brzih, sigurnih privremenih mera i dobro osmišljenih trajnih popravki. Uvek radite sa jasnim planom povratka (rollback), pravite sigurnosne kopije pre kritičnih izmena i automatizujte nadzor kako biste brzo reagovali. Investirajte vreme u dokumentovanje runbookova za najčešće incidente i sprovodite postmortem analize nakon većih zastoja — to je najefikasniji put ka smanjenju vremena zastoja i jačanju pouzdanosti sistema.

By Linux