journalctl في صفحة واحدة — tail وفلترة ومتابعة

■ space · مسار النثر

الستة، كبطاقات

سلم -p تنازلياً — journalctl -p warning..alert يأخذ نطاقاً · -p err هي حصان العمل

لماذا لا تقرأ /var/log/syslog مباشرة؟

كان تسجيل الدخول القديم في لينكس يكتب ملفات نصية تحت /var/log — syslog, auth.log, messages. systemd replaced that with استبدل systemd ذلك بـ the journal (صحيفة السجل): سجل ثنائي مفهرس تديره . Plain grep cannot read it; journalctl هي الباب الأمامي الوحيد، وفي المقابل تحصل على فلترة حسب الخدمة والوقت والإقلاع والخطورة دون بهلوانيات regex.

النموذج الذهني: الصحيفة تخزّن كل شيء، وjournalctl يستعلم عنه. الخدمة لا تحتاج ملف سجل خاصاً بها — كل ما تكتبه في stdout/stderr تحت systemd يهبط في الصحيفة تلقائياً. سجل volatile (مخزّن في /run ويُمسح عند إعادة التشغيل) لأن /var/log/journal غير موجود. أصلحه مرة واحدة:

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

تحقق: ls /var/log/journal → المجلد موجود — الإقلاعات تتراكم بدل أن تُمسح

أسطر، متابعة، وحدات

-n يقصر المخرجات على أحدث N سطراً (الافتراضي 10). --no-pager أهم مما يبدو: بدونه يفتح journalctl برنامح less ويتعلق سكربتك أو أنبوبك أو سطر ssh الأحيد بانتظار ضغطة مفتاح — أي أمر تمرّره في أنبوب ينبغي أن يحمله.

journalctl -n 100                      # last 100 lines of everything
journalctl -u nginx -n 100             # last 100 lines from one unit
journalctl -n 100 --no-pager           # print and exit — perfect for piping

هو is journalctl's tail -f الخاص بـ journalctl — يبثّ المدخلات الجديدة لحظة حدوثها. هذا هو الأمر الذي تشغّله في طرفية ثانية بينما تعيد تشغيل خدمة في الأولى: systemctl restart nginx في لوحة، وjournalctl -u nginx -f في الأخرى، وسبب الانهيار يعلن نفسه عادةً خلال ثوانٍ.

journalctl -f                    # everything, live
journalctl -u sshd -f            # just the SSH daemon, live
journalctl -u ollama -f -n 50    # live, but start with the last 50 lines

يفلتر حسب وحدة systemd — واحدة، أو عدة، أو البديل بالمطابقة التامة: filters by systemd unit — one, several, or the exact-match alternative:

journalctl -u nginx                    # one unit, all history
journalctl -u nginx -u redis           # several units at once
journalctl _SYSTEMD_UNIT=nginx.service # exact match

-u <خدمة> لا يُظهر شيئاً مع أن الخدمة تعمل بوضوح؟ قد تولد الوحدات وحدات مساعدة تحتضن المخرجات المهمة — تطبيق ويب فاشل يسجّل أحياناً في systemctl list-units --type=service | grep -i <guess>. والنمط نفسه يعمل مع المؤقتات (systemctl list-timers تُظهر الأسماء) ومع كل ما يعمل تحت systemd --user، أضف --user: journalctl --user -u pipewire -n 50.

الوقت والخطورة

--since and --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

-p يفلتر حسب الأولوية وفق سلم syslog المعروض أعلاه. عندما تتصرّف الآلة "بغرابة"، journalctl -p err -b --since today هو أسرع فحص صحّة — يجيب عن "هل هناك شيء يفشل فعلاً؟" دون ضجيج أسطر info الروتينية.

journalctl -p err -b                    # errors only, since this boot
journalctl -p warning..alert -u nginx   # a range of severities

الإقلاعات

الانهيار الذي أعدت التشغيل بعده لا يزال في الصحيفة. الخدمات التي تنهار عند الإقلاع تنتج أسطر سجل قبل إقلاعك الحالي، ويعرض journalctl بصمت الإقلاع الحالي فقط. -b يختار الإقلاعات — وهو أعلام الأوامر (flags) الأكثر فائدة لحالة "انكسر، فأعدت التشغيل، والآن لا أرى الخطأ":

journalctl -b                 # current boot only
journalctl -b -1              # previous boot
journalctl -b -1 -u sshd      # why SSH died last time
journalctl --list-boots       # index of stored boots

القرص

افحص ما يكلّفه السجل، ثم ضع سقفاً — تنظيف vacuum الآن، وسطر إعداد إلى الأبد:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # keep newest 500 MB
sudo journalctl --vacuum-time=30d      # keep newest 30 days

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

08أي سجل أولاً؟

• journalctl — سلوك التطبيقات والخدمات. كل ما يديره systemd هنا، مفهرس وقابل للفلترة. المحطة الأولى افتراضياً.
• journalctl -k / — النواة والعتاد: قتل OOM، إعادة ضبط USB، أخطاء الأقراص. إذا ماتت عملية بشكل غامض، فابحث عن قاتل OOM هنا قبل لوم التطبيق. — kernel and hardware: OOM kills, USB resets, disk errors. If a process died mysteriously, look for the OOM killer here before blaming the app.
• — للتطبيقات التي تسجّل بنفسها في ملفات فقط (سجلات وصول nginx، PostgreSQL). وحتى حينها، فإن أخطاء الإقلاع تهبط عادةً في الصحيفة. — only for apps that do their own file logging (nginx access logs, PostgreSQL). Even then, startup errors usually still land in the journal.

يمتد سير العمل نفسه إلى خدمات الذكاء الاصطناعي المحلية — عندما تتعثر وحدة ollama serve، يُظهر journalctl -u ollama -n 100 فشل تحميل النموذج فوراً. هذه هي ورقة الغش كاملة: -u للوحدة، -f للمتابعة، -n للأسطر، --since للوقت، -p للخطورة، -b للإقلاعات. ستة أعلام تغطي تقريباً كل سؤال سجل ستطرحه عليك آلة لينكس — وعندما يكون السؤال لماذا لا تبدأ خدمة systemd، فإن هذه

نهاية ورقة الغش · لم يُجلب شيء · كل شيء محلي