journalctl komutu: kullanımı, servis bazında loglar ve journal boyutunu temizleme

journalctl komutu, servislerin ve çekirdeğin systemd journal'ına bıraktığı logları seçip okumaya yarayan araçtır. systemd kullanan Linux sistemlerinde bu logları systemd-journald journal'da toplar. AlmaLinux 9 sunucusunda ve Debian 12 sunucusunda logları servise, zamana ve önceliğe göre seçip okuduğumuzda, normal bir hesap yalnızca kendi loglarını gördü ve journal'ı bellekte tutan sunucu önceki bir açılışı seçemedi.

Aşağıdaki çıktılar iki sunucudan alındı. Ana bilgisayar adları, hesaplar, açılış kimlikleri, AlmaLinux sunucusundaki işlem numaraları ve systemd paketinin sürümü örnek değerlerle değiştirildi; iki sunucu da saatleri UTC olarak yazdırdı.

1️⃣ journalctl komutunun kullanımı ve son loglar

journalctl'yi seçeneksiz çalıştırırsanız journal en eski satırından başlayarak less ekranında açılır; bu yüzden son logları görmek için satır sayısını -n ile belirleyin. -n'den sonraki sayıyı yazmazsanız 10 satır gelir.

journalctl -n 3

Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Deactivated successfully.
Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Consumed 3.934s CPU time.
Oct 28 07:14:07 server1 sudo[851987]: pam_unix(sudo:session): session closed for user user

Her satır sırasıyla zaman, ana bilgisayar adı, logu yazan program ile işlem numarası ve mesajdan oluşur. -r eklerseniz sıra tersine döner ve en yeni satır en üste çıkar. AlmaLinux sunucusundaki crond logunda en son yazılan CMDEND satırı en üstteydi.

journalctl -r -u crond -n 3

Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-f son satırı yazdırdıktan sonra kapanmaz, yeni gelen satırları yazdırmaya devam eder. Debian 12 sunucusunda -q ve -t myapp ile logger'ın son satırı ekranda bırakıldı ve logger ile iki satır daha yazıldı. Yazılan iki satır hemen altında belirdi.

journalctl -q -f -n 1 -t myapp

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test
Oct 28 07:14:35 server2 myapp[347881]: follow line 1
Oct 28 07:14:36 server2 myapp[347877]: follow line 2

-f, Ctrl+C'ye basana kadar durmaz; bu yüzden bir servis yeniden başlarken logu izlemek için kullanın.

less ekranında ekrandan geniş satırlar sağdan kesilir, kesilen kısmı ok tuşlarıyla görürsünüz. Bir boruya veya dosyaya gönderilen çıktı less'ten geçmez. less olmadan doğrudan terminale yazdırmak için --no-pager ekleyin.

2️⃣ journalctl ile servis bazında loglar

Son satırlarda birçok servisin logu karışık gelir; bu yüzden tek bir servisin logunu görmek için birim adını -u ile belirtin. Birim adının sonundaki .service yazılmayabilir.

journalctl -u crond -n 4

Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

-u'yu iki kez yazarsanız iki servisin logu zaman sırasına göre karışık gelir. AlmaLinux sunucusunda 18 Ekim 08:00 ile 08:15 arasında crond ve nginx birlikte seçildiğinde, 08:01'deki dört crond satırının ardından 08:12'deki iki nginx reload satırı geldi.

journalctl -u nginx -u crond --since '2026-10-18 08:00' --until '2026-10-18 08:15'

Oct 18 08:01:01 server1 CROND[381522]: (root) CMD (run-parts /etc/cron.hourly)
Oct 18 08:01:01 server1 run-parts[381528]: (/etc/cron.hourly) starting 0anacron
Oct 18 08:01:01 server1 run-parts[381534]: (/etc/cron.hourly) finished 0anacron
Oct 18 08:01:01 server1 CROND[381518]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 18 08:12:30 server1 systemd[1]: Reloading nginx - high performance web server...
Oct 18 08:12:30 server1 systemd[1]: Reloaded nginx - high performance web server.

systemctl status, servis durumunun altına yalnızca son 10 log satırını ekler; daha eski logları journalctl -u ile kontrol edin. Bir serviste systemctl restart komutunu çalıştırdıktan hemen sonra journalctl -u ile açılış logunu kontrol edin.

Betiklerin veya cron işlerinin logger ile yazdığı loglar birimle değil etiketle (tanımlayıcı) bulunur. -t'den sonra logger'ın -t seçeneğine yazılan adı aynen yazın.

logger -t myapp 'journalctl test message'

Debian 12 sunucusunda logger ekrana hiçbir şey yazdırmadı; yazılan satırlar -t myapp ile bulundu.

journalctl -q -t myapp

Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

-g yalnızca mesajında belirli bir metin geçen satırları bırakır. Aranan metni tamamen küçük harfle yazarsanız büyük-küçük harf ayrımı yapılmaz.

journalctl -u crond -g anacron -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron

-n satırları -g süzmeden önce saydığı için crond'un son iki satırından yalnızca anacron geçen satır kaldı.

3️⃣ Zaman aralığına ve açılışa göre loglar

--since ve --until yazdırılacak zaman aralığının başını ve sonunu belirler. Tarih ile saat arasında boşluk varsa değeri tek tırnak içine alın.

AlmaLinux sunucusunda son 2 saat, 06:01'de yazılan crond satırlarıyla başladı; aşağıda bunların ilk dördü var.

journalctl -u crond --since '-2h' | head -4

Oct 28 06:01:01 server1 CROND[802930]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 06:01:01 server1 run-parts[802936]: (/etc/cron.hourly) starting 0anacron
Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-b yalnızca geçerli açılıştan bu yana olan logları bırakır. Sunucunun neden yeniden başladığını ararken, önceki açılışın logları duruyor mu diye önce açılış listesine bakın.

journalctl -b -u crond -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

--list-boots, journal'da kalan her açılış için numarayı, açılış kimliğini ve ilk ile son satırın zamanını yazdırır.

journalctl --list-boots

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
  0 4f1c2a9be0d34c7a8e6b5d20c1f3a7e9 Sat 2026-10-17 08:29:26 UTC Wed 2026-10-28 07:16:10 UTC

AlmaLinux sunucusu journal'ı diskte tutmadığı için tek bir açılış kaydı vardı. Bu yüzden önceki açılışı belirten -b -1 yalnızca bir uyarı bırakıp sona erdi.

journalctl -b -1

Specifying boot ID or boot offset has no effect, no persistent journal was found.

Önceki bir açılışın logları -b -1 ile yalnızca journal'ı diskte (/var/log/journal) saklayan sunucularda okunabilir.

4️⃣ journalctl hata logları ve çekirdek logları

-p satırları logun öncelik düzeyine göre seçer. Tek bir düzey yazarsanız o düzey ve ondan daha önemli tüm düzeyler gelir; düzeyi adla ya da sayıyla yazabilirsiniz.

logger ile err düzeyinde bir satır yazılıp -p err ile seçildiğinde, aynı etiketteki notice düzeyli satır (journalctl test message) düştü ve yalnızca err satırı kaldı.

logger -t myapp -p user.err 'journalctl error test'; journalctl -q -t myapp -p err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

İki düzeyi iki noktayla bağlarsanız yalnızca o aralık yazdırılır. warning..err seçildiğinde yalnızca uyarı ve hata düzeyleri kalır.

journalctl -q -t myapp -p warning..err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

-k yalnızca çekirdek mesajlarını bırakır ve yalnızca geçerli açılıştan bu yana olan satırları yazdırır.

journalctl -k -n 3

Oct 26 10:14:25 server1 systemd-rc-local-generator[96245]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 10:47:57 server1 systemd-rc-local-generator[512078]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 11:01:10 server1 systemd-rc-local-generator[520023]: /etc/rc.d/rc.local is not marked executable, skipping.

AlmaLinux sunucusunda -k çıktısının son üç satırının hepsi systemd-rc-local-generator satırıydı. Bu satırlar çekirdek log arabelleğine yazılmış mesajlar olduğu için _TRANSPORT değeri kernel olarak saklanır ve -k ile de görünür.

5️⃣ journalctl çıktı biçimleri

-o her satırın biçimini değiştirir. Varsayılan short, bir syslog dosyasıyla neredeyse aynı biçimdedir; short-iso ise zamanı saat dilimi dahil ISO 8601 biçimine çevirir. AlmaLinux sunucusunda short-iso'ya geçince zamanın sonuna +0000 eklendi.

journalctl -u crond -n 2 -o short-iso

2026-10-28T07:01:01+0000 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
2026-10-28T07:01:01+0000 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

cat zamanı ve ana bilgisayar adını çıkarıp yalnızca mesajı yazdırır; mesajları grep'e veya başka bir programa aktarırken kullanın.

journalctl -u crond -n 2 -o cat

(/etc/cron.hourly) starting 0anacron
(root) CMDEND (run-parts /etc/cron.hourly)

json ve json-pretty, journal'da saklanan alanları ad ve değer olarak yazdırır. --output-fields ile alan seçtiğinizde imleç, zaman ve açılış kimliği alanları her zaman birlikte gelir. Debian 12 sunucusunda yalnızca dört alan seçildiğinde bile __CURSOR, _BOOT_ID ve iki zaman alanı da çıktı.

journalctl -q -t myapp -n 1 -o json-pretty --output-fields=MESSAGE,PRIORITY,SYSLOG_IDENTIFIER,_PID

{
	"__REALTIME_TIMESTAMP" : "1793171676664200",
	"_PID" : "347877",
	"SYSLOG_IDENTIFIER" : "myapp",
	"MESSAGE" : "follow line 2",
	"__CURSOR" : "s=2a6f0c1d9e8b47a3b5c4d3e2f1a0b9c8;i=1a2b3;b=b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47;m=17cf8fe36f5;t=65ee150cf1188;x=1f2e3d4c5b6a7980",
	"_BOOT_ID" : "b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47",
	"PRIORITY" : "5",
	"__MONOTONIC_TIMESTAMP" : "1636264982261"
}

6️⃣ Journal'ın saklandığı yer ve boyutunu temizleme

Journal'ın bellekte mi diskte mi duracağını journald.conf dosyasındaki Storage= değeri belirler. Varsayılan auto, /var/log/journal klasörü varsa diske, yoksa belleğe (/run/log/journal) kaydeder.

AlmaLinux sunucusunda /var/log/journal klasörü yoktu; journal yalnızca /run/log/journal içindeydi.

ls -ld /var/log/journal /run/log/journal

ls: cannot access '/var/log/journal': No such file or directory
drwxr-sr-x+ 4 root systemd-journal 80 Oct 17 08:30 /run/log/journal

Debian 12 sunucusunda iki klasör de vardı ve journal diskte birikiyordu.

ls -ld /var/log/journal /run/log/journal

drwxr-sr-x+ 2 root systemd-journal   40 Oct  9 08:43 /run/log/journal
drwxr-sr-x+ 4 root systemd-journal 4096 Sep 24 12:52 /var/log/journal

Logları yeniden başlatmadan sonra da tutmak için journald.conf içindeki Storage= değerini persistent yapın ve systemd-journald'ı yeniden başlatın. Resmî kılavuza göre /var/log/journal klasörü gerektiğinde otomatik oluşturulur. Bu yazı için ayarlar değiştirilmedi.

Diskte kalan journal, bir olaydan sonra çıkarılıp okunan uçak kara kutusu gibidir.

--disk-usage, arşivlenmiş journal dosyalarıyla şu anda kullanılan dosyaların toplam boyutunu yazdırır. Debian 12 sunucusundaki normal bir hesapta, en üstteki [Hint] uyarısı -q ile gizlendiğinde sonuç tek satırdı: 6.6M.

journalctl -q --disk-usage

Archived and active journals take up 6.6M in the file system.

Diske kaydedilen journal'ın en büyük boyutu SystemMaxUse= ile belirlenir. Değer yazılmazsa üst sınır dosya sistemi boyutunun yüzde 10'udur (en fazla 4G); Debian 12 sunucusunun journald.conf dosyasında 50M yazıyordu.

grep -v '^#' /etc/systemd/journald.conf | grep -v '^$'

[Journal]
SystemMaxUse=50M

Eski journal'ları hemen küçültmek için tutulacak boyutu --vacuum-size ile, tutulacak süreyi --vacuum-time ile belirleyin. İki komut da journal dosyalarını sildiği için bu yazıda çalıştırılmadı.

journalctl --vacuum-size=200M

--vacuum-size=200M, arşivlenmiş journal dosyalarını en eskiden başlayarak siler ve toplam boyutu 200M'nin altına indirir.

journalctl --vacuum-time=2weeks

--vacuum-time=2weeks, yalnızca 2 haftadan eski satırlar içeren arşiv dosyalarını siler.

vacuum yalnızca arşivlenmiş dosyaları siler, şu anda kullanılan dosyaları bırakır; bu yüzden çalıştırdıktan sonra bile --disk-usage değeri belirtilen boyuta kadar düşmeyebilir.

/var/log altındaki metin loglarını yazan rsyslog, journald'dan ayrı çalışır. Bu yüzden iki logun okuma yolu da boyut yönetimi de farklıdır.

7️⃣ journalctl komutunda okuma izni ve seçenekler

🔲 Okuma izni

journalctl'yi root dışındaki bir hesapla çalıştırırsanız en üstte bir [Hint] metni çıkar ve yalnızca o hesabın yazdığı loglar görünür. Debian 12 sunucusunda normal bir hesapla nginx logları arandığında uyarının ardından yalnızca [-- No entries --] çıktı.

journalctl -u nginx -n 5

Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.
-- No entries --

id -nG sonucuna göre bu hesap yalnızca bir gruba üyeydi; uyarının söz ettiği adm veya systemd-journal gruplarında değildi.

id -nG

user

Resmî kılavuz, systemd-journal, adm ve wheel gruplarındaki hesapların tüm journal'ı okuyabildiğini açıklar. adm ve wheel dağıtımın belirlediği başka izinleri de getirir ve wheel çoğu zaman yönetim işlerine de izin verir; bu yüzden yalnızca log okuyacak bir hesap için doğru grup systemd-journal'dır.

usermod -aG systemd-journal user

Grubu ekleyen usermod komutu bu yazıda çalıştırılmadı. Grubu ekledikten sonra yeniden oturum açın ve grupları id -nG ile kontrol edin. Yönetici yetkisi olan bir hesap sudo journalctl ile çalıştırınca da tüm logları görür.

[Hint] metni -q ile gizlenir. Ancak -q eklense de görünen loglar yalnızca o hesabın yazdığı satırlardır. --user o hesabın kullanıcı journal'ını okur ve yalnızca journal'ı diske kaydeden sunucularda çalışır. Journal'ı diskte tutan Debian 12 sunucusunda o hesabın systemd ve logger satırları çıktı.

journalctl --user -n 3

Oct 28 07:12:35 server2 systemd[347665]: Reached target default.target - Main User Target.
Oct 28 07:12:35 server2 systemd[347665]: Startup finished in 181ms.
Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

🔲 journalctl komutu seçenekleri

📌 Başlıca seçenekler: bu yazıda çalıştırılan sonuçlar

📎 Diğer seçenekler: resmî kılavuza göre

🔲 journalctl komutu simülatörü

Aşağıdaki simülatörde son logları, servis bazında logları, zaman aralığını, önceliği ve çıktı biçimini komut yazarak kendiniz deneyebilirsiniz.

🔢 SSS & önerilen içerikler

🧭 Sistem bilgisi · ayar komutları: önerilen içerikler 8 yazı · 2 kaynak

🗂️ Sistem bilgisi · ayar komutları

▸📂 Sistem bilgisi4

📄 CPU · RAM · disk · işletim sistemi bilgisi 📄 uname · çekirdek sürümü 📄 free komutu 📄 uptime komutu

▸📂 Ayarlar2

📄 timedatectl komutu 📄 localectl komutu

▸📂 Loglar2

📄 logrotate 📄 journalctl komutu

▸🪐 Kaynaklar2

📡 journalctl(1) — systemd 252 📡 journald.conf(5) — systemd 252

Linux · Sistem bilgisi

Linux'ta CPU kontrolü: RAM, disk ve işletim sistemi bilgisi komutları

Linux'ta CPU çekirdek sayısı tek satırla hemen çıkar: [nproc].

Yazıyı oku →Şu anki yazı

Linux · Sistem bilgisi

Linux çekirdek sürümünü kontrol etme komutları ve dağıtım sürümünü kontrol etme yöntemi

Linux'u yönetirken Linux çekirdek sürümünü ve dağıtım sürümünü kontrol etmeniz gereken durumlar olur.

Yazıyı oku →Şu anki yazı

Linux · Sistem bilgisi

Linux free komutu: bellek durumunu kontrol etme

Linux free komutu, sunucunun bellek kullanımını ve boş belleğini gösteren bir komuttur; bellek bilgisini /proc/meminfo'dan okur.

Yazıyı oku →Şu anki yazı

Linux · Sistem bilgisi

Linux uptime komutu (sunucu çalışma süresi & 1, 5, 15 dakikalık ortalama yük)

Linux uptime komutu sistemin ortalama yükünü ve sunucunun ne kadar süredir çalıştığını gösterir.

Yazıyı oku →Şu anki yazı

Linux · Ayarlar

Linux sunucu saat senkronizasyonu: timedatectl (CentOS 7 ve sonrası)

Linux'ta tarih ve saat ayarı gereklidir; çünkü sunucu çalışırken saat yanlışsa girilen DB verilerinin, log verilerinin ve web sunucusuna erişim kayıtlarının zamanları tutmayabilir.

Yazıyı oku →Şu anki yazı

Linux · Ayarlar

[Linux] localectl komutu

CentOS 7'den itibaren birçok komut birleşik biçimde sunulur.

Yazıyı oku →Şu anki yazı

Linux · Loglar

Linux Logrotate: kavram ve ayarlar

Linux Logrotate, "logları döndürmek" ifadesinden de anlaşılacağı gibi log ve rotate sözcüklerinin birleşimidir.

Yazıyı oku →Şu anki yazı

Linux · Loglar

journalctl komutu: kullanımı, servis bazında loglar ve journal boyutunu temizleme

journalctl komutu, servislerin ve çekirdeğin systemd journal'ına bıraktığı logları seçip okumaya yarayan araçtır ve systemd kullanan Linux sistemlerinde bu logları systemd-journald journal'da toplar.

Yazıyı oku →Şu anki yazı

📡journalctl(1) — systemd 252 📡journald.conf(5) — systemd 252

ℹ️ Satış ortaklığı bildirimi
Bu sitenin içeriklerinde satış ortaklığı bağlantıları bulunur. Bir ziyaretçi bu bağlantılar üzerinden ürün veya hizmet satın alırsa bu site satıcıdan komisyon alır. Bu süreçte alıcının ödediği tutar ^{(kampanya indirimlerinde tutar düşer↓)} artmaz. Yayımlanan fiyat, indirim ve stok bilgileri yazının yazıldığı zamana aittir ve gerçek durumdan farklı olabilir; bu yüzden satın almadan önce son bilgiyi satıcıdan kontrol etmenizi rica ederiz. Ürünler kendi ölçütlerimize göre seçilir ve değerlendirilir; komisyon alınıp alınmaması tanıtım sırasını veya değerlendirme içeriğini etkilemez.