journalctl Cheat Sheet: Linux Loglarını İzleme ve Filtreleme

journalctl tek satırda: journalctl -u <service> -f canlı servis logunu takip eder, journalctl -u <service> -n 100 son 100 satırı gösterir, journalctl --since "1 hour ago" yakın zamanlı her şeyi listeler. “Bu servis neden düştü” anlarının %90’ını bu üçlü karşılar. Bu cheat sheet’in geri kalanı, gece 2’de man sayfasını baştan okumaktan kurtaran kopyala-yapıştır kalıpları — birime, zamana, önceliğe ve açılışa göre filtreleme; ayrıca günlüğün diskinizi yemesini engelleyen temizlik komutları. Aşağıdaki her komut, systemd kullanan her dağıtımda (Ubuntu, Debian, Fedora, Arch) olduğu gibi çalışır.

journalctl nedir, neden /var/log/syslog yerine onu okumalıyım?

Eski usul Linux loglaması /var/log altına düz metin dosyaları yazardı — syslog, auth.log, messages. systemd bunların yerine günlüğü (journal) koydu: systemd-journald tarafından yönetilen, ikili ve indeksli bir log. Düz grep onu okuyamaz; journalctl tek giriş kapısıdır ve karşılığında servis, zaman, açılış ve önem derecesine göre, regex akrobatikleri olmadan filtreleme alırsınız.

Zihinsel model basit: günlük her şeyi saklar, journalctl ise sorgu aracıdır. Bir servisin kendi log dosyasına ihtiyacı yoktur — systemd altında çalışırken stdout/stderr’a yazdığı her şey otomatik olarak günlüğe düşer. Bu yüzden nginx’in hata logunu nereye yazdırdığı hakkında hiçbir fikriniz olmasa bile journalctl -u nginx çalışır.

Bir uyarı: bazı minimal kurulumlarda günlük geçicidir (volatile) — /var/log altında değil /run altında tutulur ve reboot’ta silinir; çünkü /var/log/journal yoktur. Bir kereye mahsus düzeltin:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

Bir logun son 100 satırını nasıl görürüm?

-n, çıktıyı en yeni N satırla sınırlar (varsayılan 10):

journalctl -n 100                      # her şeyin son 100 satırı
journalctl -u nginx -n 100             # tek bir birimin son 100 satırı
journalctl -n 100 --no-pager           # yaz ve çık — pipe için birebir

--no-pager göründüğünden daha önemli: olmadan journalctl less açar ve betiğiniz, pipe’ınız ya da ssh tek satırlığınız bir tuş basılmasını bekleyip kalır. İlerisine pipe’ladığınız her komut bu bayrağı taşımalı.

Logları tail -f gibi canlı nasıl takip ederim?

-f flag’i, journalctl’in tail -f‘sidir — yeni girdileri oluştuğu anda akıtır:

journalctl -f                    # her şey, canlı
journalctl -u sshd -f            # yalnızca SSH daemon'u, canlı
journalctl -u ollama -f -n 50    # canlı, ama son 50 satırdan başla

Bir servisi ilk terminalde yeniden başlatırken ikinci terminalde çalıştırılacak komut budur: bir panede systemctl restart nginx, öbüründe journalctl -u nginx -f — çökmenin sebebi genellikle birkaç saniye içinde kendiliğinden ortaya çıkar. Ben bu döngüyü homelab‘ımda, bir konteyner ya da servis yaramazlık yaptığında her seferinde çalıştırırım.

Belirli bir servisin loglarını nasıl gösteririm?

-u, systemd unit’ine göre filtreler:

journalctl -u nginx                    # tek unit, tüm geçmiş
journalctl -u nginx -u redis           # birkaç unit aynı anda
journalctl _SYSTEMD_UNIT=nginx.service # birebir eşleşen alternatif

Unit’ler, ilginç çıktıyı üzerlerinde tutan yardımcı unit’ler üretebilir — çöken bir web uygulaması bazen gerçek hatayı başka bir unit altına loglar. -u <service> boş dönerken servis görünürde çalışıyorsa, önce gerçek unit adını bulun:

systemctl list-units --type=service | grep -i <guess>

Aynı -u kalıbı timer’lar için de çalışır (isimleri systemctl list-timers verir) ve kullanıcı servisleri için de — systemd --user altında çalışan her şey için --user ekleyin:

journalctl --user -u pipewire -n 50

Logları zamana göre nasıl filtrelerim?

--since ve --until zaman damgası alır ama affedici göreli ifadeleri de kabul eder:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Bir zaman aralığını bir unit ile eşleştirin, olay triyajı tek satırda: “API, 09:00 ile düştüğü saat arasında ne logladı?” Tek makine için, herhangi bir log toplayıcısından hızlıdır.

Yalnızca hataları (veya uyarıları) nasıl gösteririm?

-p, syslog önem adlarını kullanarak önceliğe göre filtreler:

journalctl -p err -b              # yalnızca hatalar, bu açılıştan beri
journalctl -p warning..alert -u nginx   # bir önem aralığı

Öncelikler, azalan sırayla: emerg, alert, crit, err, warning, notice, info, debug. Bir makine “tuhaf davranmaya” başladığında journalctl -p err -b --since today en hızlı akıl sağlığı testidir — rutin info satırlarının gürültüsü olmadan “gerçekten bir şey mi başarısız oluyor?” sorusunu yanıtlar.

Önceki açılışın loglarını nasıl görürüm?

Açılışta çöken servisler, güncel boot’unuzdan önceye ait log satırları üretir ve journalctl varsayılan olarak yalnızca güncelini gösterir. -b boot seçer:

journalctl -b                 # yalnızca güncel açılış
journalctl -b -1              # önceki açılış
journalctl -b -1 -u sshd      # SSH geçen sefer neden öldü
journalctl --list-boots       # saklanan boot'ların dizini

“Bozuldu, reboot ettim, şimdi hatayı göremiyorum” senaryosu için en işe yarar tek flag budur — hata hâlâ oradadır, bir boot geride.

Hızlı başvuru: ezbere bilinmesi gereken flag’ler

Amaç	Komut
Tek servisi canlı takip et	journalctl -u <svc> -f
Son 100 satır	journalctl -n 100
Bir saat öncesinden beri	journalctl --since "1 hour ago"
Bu açılışın hataları	journalctl -p err -b
Önceki açılış	journalctl -b -1
Günlüğün disk kullanımı	journalctl --disk-usage
Makine tarafından okunabilir çıktı	journalctl -o json-pretty
Yalnızca çekirdek mesajları	journalctl -k

Günlüğün diskimi doldurmasını nasıl engellerim?

Önce maliyetine bakın, sonra tavan çekin:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # en yeni 500 MB'ı tut
sudo journalctl --vacuum-time=30d      # en yeni 30 günü tut

Tavanı kalıcı yapmak için /etc/systemd/journald.conf içindeki [Journal] bölümüne SystemMaxUse=500M yazın, ardından sudo systemctl restart systemd-journald. Boyut tavanı ile yukarıdaki boot filtresi bir arada olunca günlük bir araç olarak kalır — yavaş bir disk sızıntısı değil.

journalctl mi, dmesg mi, /var/log mu — önce hangisine bakılır?

• journalctl — uygulama ve servis davranışı. systemd’in yönettiği her şey buradadır; indeksli ve filtrelenebilir. Varsayılan ilk durak.
• journalctl -k / dmesg — çekirdek ve donanım: OOM öldürmeleri, USB resetleri, disk hataları. Bir süreç açıklanamayacak şekilde öldüyse, uygulamayı suçlamadan önce OOM killer’ı burada arayın.
• /var/log/<app>/ — yalnızca kendi dosya loglamasını yapan uygulamalar için (nginx access logları, PostgreSQL). Orada bile açılış hataları çoğunlukla yine günlüğe düşer.

Aynı iş akışı yerel yapay zekâ servislerine de uzanır — bir ollama serve unit’i takıldığında journalctl -u ollama -n 100, model yükleme hatasını hemen gösterir; ayrıntı Ollama vs LM Studio karşılaştırmasında.

Cheat sheet’in tamamı buydu: unit için -u, takip için -f, satır için -n, zaman için --since, önem için -p, açılış için -b. Altı flag, bir Linux makinesinin size soracağı neredeyse her log sorusunu karşılar.