ورقة أوامر journalctl: تتبع وفلترة سجلات لينكس

journalctl في سطر واحد: journalctl -u <service> -f يتابع سجل خدمة حية، وjournalctl -u <service> -n 100 يعرض آخر 100 سطر، وjournalctl --since "1 hour ago" يعرض كل ما جرى حديثًا. هذا يغطي 90% من لحظات “لماذا توقفت هذه الخدمة عن العمل”. وبقية الورقة هي أنماط جاهزة للنسخ تُغنيك عن إعادة قراءة صفحة الدليل في الثانية صباحًا — الفلترة بالوحدة والزمن والأولوية والإقلاع، إضافة إلى أوامر التنظيف التي تمنع السجل من التهام قرصك. كل أمر أدناه يعمل كما هو على أي توزيعة systemd (Ubuntu وDebian وFedora وArch).

ما هو journalctl، ولماذا لا نقرأ /var/log/syslog مباشرة؟

تسجيل لينكس القديم كان يكتب ملفات نصية تحت /var/log — syslog وauth.log وmessages. واستبدل systemd ذلك بـ السجل المركزي (the journal): سجل ثنائي مفهرس تديره systemd-journald. لا يستطيع grep العادي قراءته؛ فـ journalctl هو الباب الأمامي الوحيد، وفي المقابل تحصل على فلترة حسب الخدمة والزمن والإقلاع والخطورة بلا بهرجة تعابير نمطية.

النموذج الذهني بسيط: السجل يخزّن كل شيء، وjournalctl أداة الاستعلام. الخدمة لا تحتاج ملف سجل خاصًا بها — أي ما تكتبه إلى stdout/stderr أثناء عملها تحت systemd يهبط في السجل تلقائيًا. ولهذا يعمل journalctl -u nginx حتى وأنت لا تعرف أين ضبط nginx ملف سجل الأخطاء.

تنبيه واحد: في بعض التثبيتات المصغرة يكون السجل متطايرًا (محفوظًا في /run ويُمسح عند كل إعادة تشغيل) لأن /var/log/journal غير موجود. أصلحه مرة واحدة:

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

كيف أرى آخر 100 سطر من السجل؟

الخيار -n يحدّ الناتج بأحدث N سطرًا (الافتراضي 10):

journalctl -n 100                      # آخر 100 سطر من كل شيء
journalctl -u nginx -n 100             # آخر 100 سطر من وحدة واحدة
journalctl -n 100 --no-pager           # اطبع واخرج — مثالي للتمرير عبر أنابيب

و--no-pager أهم مما تبدو: بدونه يفتح journalctl برنامج less ويتعليق سكربتك أو أنبوبك أو سطرك الواحد عبر ssh بانتظار ضغطة مفتاح. أي أمر ستمرر ناتجه فيص فليحمل هذا الخيار.

كيف أتابع السجلات مباشرة مثل tail -f؟

الخيار -f هو tail -f الخاص بـ journalctl — يبثّ المدخلات الجديدة لحظة وقوعها:

journalctl -f                    # كل شيء، مباشرة
journalctl -u sshd -f            # عفريت SSH وحده، مباشرة
journalctl -u ollama -f -n 50    # مباشرة، لكن يبدأ بآخر 50 سطرًا

هذا هو الأمر الذي تشغّله في طرفية ثانية بينما تعيد تشغيل خدمة في الأولى: systemctl restart nginx في نافذة، وjournalctl -u nginx -f في الأخرى، وسبب الانهيار يعرف نفسه عادة في ثوانٍ. أنا أشغّل هذه الحلقة نفسها على homelab الخاص بي كلما أساء حاوية أو خدمة السلوك.

كيف أعرض سجلات خدمة معينة؟

الخيار -u يرشّح حسب وحدة systemd:

journalctl -u nginx                    # وحدة واحدة، كامل التاريخ
journalctl -u nginx -u redis           # عدة وحدات دفعة واحدة
journalctl _SYSTEMD_UNIT=nginx.service # البديل بالمطابقة التامة

قد تُنشئ الوحدات وحدات مساعدة تحتفظ بالناتج المهم — أحيانًا يسجل تطبيق ويب فاشل الخطأ الحقيقي تحت وحدة مختلفة. إذا أظهر -u <service> شيئًا والخدمة تعمل بوضوح، اعرف اسم الوحدة الفعلي أولًا:

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

النمط نفسه مع -u يعمل مع المؤقتات (systemctl list-timers يعرض الأسماء) وخدمات المستخدم — لأي شيء يعمل تحت systemd --user أضف --user:

journalctl --user -u pipewire -n 50

كيف أرشّح السجلات بالزمن؟

--since و--until تقبلان أزمنة صريحة، لكنهما يفهمان أيضًا صيغًا نسبية متساهلة:

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

اربط نافذة زمنية بوحدة وستحصل على فرز الحادث في سطر واحد: “ماذا سجّل الـ API بين 09:00 ولحظة سقوطه؟” هذا أسرع من أي مجمّع سجلات لجهاز واحد.

كيف أعرض الأخطاء فقط (أو التحذيرات)؟

الخيار -p يرشّح حسب الأولوية بأسماء شدة syslog:

journalctl -p err -b              # الأخطاء فقط، منذ هذا الإقلاع
journalctl -p warning..alert -u nginx   # نطاق من درجات الشدة

الأولويات تنازليًا: emerg وalert وcrit وerr وwarning وnotice وinfo وdebug. عندما “يتصرف الجهاز بغرابة”، فإن journalctl -p err -b --since today أسرع فحص عقلاني — يجيب عن “هل يفشل شيء فعلًا؟” بلا ضجيج أسطر info الروتينية.

كيف أرى سجلات الإقلاع السابق؟

الخدمات التي تنهار عند الإقلاع تكتب أسطر سجل قبل إقلاعك الحالي، وjournalctl يعرض الحالي بصمت فقط. الخيار -b يختار الإقلاعات:

journalctl -b                 # الإقلاع الحالي فقط
journalctl -b -1              # الإقلاع السابق
journalctl -b -1 -u sshd      # لماذا مات SSH في المرة الماضية
journalctl --list-boots       # فهرس الإقلاعات المحفوظة

هذا هو الخيار الأنفع إطلاقًا لحالة “انهار وأعدت التشغيل ولم أعد أرى الخطأ” — الخطأ لا يزال هناك، إقلاعًا واحدًا في الخلف.

مرجع سريع: الخيارات التي تستحق الحفظ

الهدف	الأمر
متابعة خدمة واحدة حية	journalctl -u <svc> -f
آخر 100 سطر	journalctl -n 100
منذ ساعة	journalctl --since "1 hour ago"
أخطاء هذا الإقلاع	journalctl -p err -b
الإقلاع السابق	journalctl -b -1
حجم السجل على القرص	journalctl --disk-usage
ناتج قابل للقراءة آليًا	journalctl -o json-pretty
رسائل النواة فقط	journalctl -k

كيف أمنع السجل من ملء قرصي؟

اعرف التكلفة ثم ضع سقفًا:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # احتفظ بأحدث 500 ميغابايت
sudo journalctl --vacuum-time=30d      # احتفظ بأحدث 30 يومًا

ولجعل السقف دائمًا، اضبط SystemMaxUse=500M تحت قسم [Journal] في /etc/systemd/journald.conf ثم sudo systemctl restart systemd-journald. بين سقف الحجم وفلتر الإقلاع أعلاه، يبقى السجل أداة لا تسريبًا بطيئًا للقرص.

journalctl مقابل dmesg مقابل /var/log — أين أفحص أولًا؟

• journalctl — سلوك التطبيقات والخدمات. كل ما تديره systemd موجود هنا، مفهرسًا وقابلًا للترشيح. المحطة الافتراضية الأولى.
• journalctl -k / dmesg — النواة والعتاد: قتل OOM، إعادة ضبط USB، أخطاء الأقراص. إذا ماتت عملية بغموض، ابحث عن قاتل OOM هنا قبل إلقاء اللوم على التطبيق.
• /var/log/<app>/ — فقط للتطبيقات التي تدير ملفات سجلها بنفسها (سجلات وصول nginx، PostgreSQL). وحتى حينها، أخطاء الإقلاع تهبط عادة في السجل المركزي.

نفس سير العمل يمتد لخدمات الذكاء الاصطناعي المحلية — حين تتعثر وحدة ollama serve، يعرض journalctl -u ollama -n 100 فشل تحميل النموذج فورًا، كما في مقارنة Ollama مع LM Studio.

هذه هي الورقة كاملة: -u للوحدة، و-f للمتابعة، و-n للأسطر، و--since للزمن، و-p للشدة، و-b للإقلاعات. ستة خيارات تغطي تقريبًا كل سؤال سجل سيطرحه عليك جهاز لينكس.