/etc/systemd/journald.conf

/run/systemd/journald.conf

/usr/local/lib/systemd/journald.conf

/usr/lib/systemd/journald.conf

/etc/systemd/journald.conf.d/*.conf

/run/systemd/journald.conf.d/*.conf

/usr/local/lib/systemd/journald.conf.d/*.conf

/usr/lib/systemd/journald.conf.d/*.conf

/etc/systemd/journald@NAMESPACE.conf

/etc/systemd/journald@NAMESPACE.conf.d/*.conf

/run/systemd/journald@NAMESPACE.conf.d/*.conf

/usr/local/lib/systemd/journald@NAMESPACE.conf.d/*.conf

/usr/lib/systemd/journald@NAMESPACE.conf.d/*.conf

يتحكم في مكان تخزين بيانات اليومية. واحدة من "volatile"، "persistent"، "auto" و "none". إذا كانت "volatile"، تخزن بيانات سجل اليومية فقط في الذاكرة، أي أسفل تسلسل /run/log/journal (الذي ينشأ عند الحاجة). إذا كانت "persistent"، تخزن البيانات بشكل مفضل على القرص، أي أسفل تسلسل /var/log/journal (الذي ينشأ عند الحاجة)، مع الرجوع إلى /run/log/journal (الذي ينشأ عند الحاجة)، أثناء الإقلاع المبكر وإذا كان القرص غير قابل للكتابة. تتصرف "auto" مثل "persistent" إذا كان الدليل /var/log/journal موجوداً، و "volatile" بخلاف ذلك (وجود الدليل يتحكم في وضع التخزين). تقوم "none" بإيقاف جميع التخزين، تسقط جميع بيانات السجل المستلمة (لكن إعادة التوجيه إلى أهداف أخرى، مثل وحدة التحكم، مخزن سجل النواة، أو مقبس syslog ستظل تعمل). المبدئي هو "persistent" في نطاق اليومية المبدئي (تحدد هذه القيمة في وقت التجميع)، و "persistent" في جميع النطاقات الأخرى.

لاحظ أن journald سيستخدم مبدئيًا التخزين المتطاير، حتى يؤدي استدعاء journalctl --flush (أو إرسال SIGUSR1 إلى journald) إلى تحوله إلى التسجيل المستمر (تحت الشروط المذكورة أعلاه). يُفعل هذا تلقائيًا عند الإقلاع عبر "systemd-journal-flush.service".

لاحظ أنه عندما يغير هذا الخيار إلى "volatile"، لا تزال البيانات المستمرة الموجودة. في الاتجاه الآخر، يمكن استخدام journalctl(1) مع الخيار --flush لنقل البيانات المتطايرة إلى تخزين مستمر.

عند استخدام نطاقات اليومية (انظر LogNamespace= في systemd.exec(5))، لن يؤثر تعيين Storage= إلى "volatile" أو "auto" على إنشاء دليل سجلات لكل نطاق في /var/log/journal/، لأن ملف خدمة systemd-journald@.service يحمل مبدئياً LogsDirectory=. لإيقاف ذلك، أضف ملف إضافة وحدة يحدد LogsDirectory= إلى سلسلة فارغة.

لاحظ أن ملفات اليومية لكل مستخدم غير مدعومة ما لم يتم تمكين التخزين المستمر، مما يجعل journalctl --user غير متاح.

يمكن أيضًا تحديد التخزين المستخدم عبر بيانات الاعتماد "journal.storage". تعطي القيم المهيأة عبر ملفات التهيئة أولوية على القيم المهيأة عبر بيانات الاعتماد.

أُضيف في الإصدارة 186.

يمكن أن يأخذ قيمة منطقية. إذا تم تمكينه (المبدئي)، تضغط كائنات البيانات التي ستخزن في اليومية وتكون أكبر من الحد المبدئي البالغ 512 بايت قبل كتابتها إلى نظام الملفات. يمكن أيضًا تعيينه إلى عدد من البايتات لتحديد حد الضغط مباشرة. يمكن استخدام لواحق مثل K و M و G لتحديد وحدات أكبر.

يأخذ قيمة منطقية. إذا تم تمكينه (المبدئي)، وكان مفتاح الختم متاحاً (كما ينشأ بواسطة أمر journalctl(1)'s --setup-keys)، يتم تمكين الختم الآمن الأمامي (FSS) لجميع ملفات اليومية المستمرة. يعتمد FSS على مولدات المفاتيح المتسلسلة القابلة للبحث[2] بواسطة G. A. Marson و B. Poettering (doi:10.1007/978-3-642-40203-6_7) ويمكن استخدامه لحماية ملفات اليومية من التعديل غير الملحوظ.

أُضيف في الإصدارة 189.

يتحكم في تقسيم ملفات اليومية لكل مستخدم، إما "uid" أو "none". ملفات اليومية المقسمة مفيدة بشكل أساسي للتحكم في الوصول: على UNIX/Linux، يدير التحكم في الوصول لكل ملف، وسيعين برنامج اليومية الخفي للمستخدمين حق الوصول للقراءة إلى ملفات اليومية الخاصة بهم. إذا كانت "uid"، سيحصل جميع المستخدمين العاديين (مع UID خارج نطاق مستخدمي النظام، مستخدمي الخدمة الديناميكيين، ومستخدم nobody) على ملفات اليومية الخاصة بهم، وسيسجل مستخدمو النظام في اليومية النظامية. انظر المستخدمون، المجموعات، UIDs و GIDs على أنظمة systemd[3] لمزيد من التفاصيل حول نطاقات UID. إذا كانت "none"، لا تقسم ملفات اليومية حسب المستخدم وتخزن جميع الرسائل بدلاً من ذلك في اليومية النظامية الواحدة. في هذا الوضع، لا يتمتع المستخدمون غير المميزين عموماً بإمكانية الوصول إلى بيانات السجل الخاصة بهم. لاحظ أن تقسيم ملفات اليومية حسب المستخدم متاح فقط لليوميات المخزنة بشكل مستمر. إذا خزنت اليوميات على تخزين متطاير (انظر Storage= أعلاه)، يستخدم ملف يومية واحد فقط. المبدئي هو "uid".

أُضيف في الإصدارة 190.

يهيئ تحديد المعدل المطبق على جميع الرسائل المولدة على النظام. إذا، في الفاصل الزمني المعرف بواسطة RateLimitIntervalSec=، تم تسجيل رسائل أكثر من المحدد في RateLimitBurst= بواسطة خدمة، تسقط جميع الرسائل الإضافية داخل الفاصل حتى ينتهي الفاصل. تولد رسالة حول عدد الرسائل المسقطة. يطبق تحديد المعدل هذا لكل خدمة، بحيث لا تتداخل خدمتان تسجلان مع حدود بعضهما البعض. المبدئي هو 10000 رسالة في 30 ثانية. يمكن تحديد المواصفات الزمنية لـ RateLimitIntervalSec= بالوحدات التالية: "s"، "min"، "h"، "ms"، "us". لإيقاف أي نوع من تحديد المعدل، عين أي من القيمتين إلى 0.

لاحظ أن حد المعدل الفعال يضرب بعامل مشتق من مساحة القرص الحرة المتاحة لليومية. حالياً، يحسب هذا العامل باستخدام اللوغاريتم للأساس 2.

جدول 1. مثال تعديلات معدل RateLimitBurst= حسب مساحة القرص
المتاحة

مساحة القرص المتاحة	مضاعف الاندفاع
<= 1MB	1
<= 16MB	2
<= 256MB	3
<= 4GB	4
<= 64GB	5
<= 1TB	6

إذا قدمت خدمة حدود معدل لنفسها عبر LogRateLimitIntervalSec= و/أو LogRateLimitBurst= في systemd.exec(5)، ستتجاوز تلك القيم الإعدادات المحددة هنا.

يفرض حدود الحجم على ملفات اليومية المخزنة. تنطبق الخيارات المسبوقة بـ "System" على ملفات اليومية عند تخزينها على نظام ملفات مستمر، وبشكل أكثر تحديداً /var/log/journal. تنطبق الخيارات المسبوقة بـ "Runtime" على ملفات اليومية عند تخزينها على نظام ملفات متطاير في الذاكرة، وبشكل أكثر تحديداً /run/log/journal. يستخدم الأول فقط عندما يكون /var/ موصولاً وقابلاً للكتابة، والدليل /var/log/journal موجوداً. بخلاف ذلك، ينطبق الأخير فقط. لاحظ أن هذا يعني أنه أثناء الإقلاع المبكر وإذا قام المسؤول بتعطيل التسجيل المستمر، تنطبق خيارات الأخير فقط، بينما ينطبق الأول إذا تم تمكين التسجيل المستمر وتم إقلاع النظام بالكامل. يتجاهل journalctl و systemd-journald جميع الملفات ذات الأسماء التي لا تنتهي بـ ".journal" أو ".journal~"، لذلك تؤخذ فقط هذه الملفات، الموجودة في الدلائل المناسبة، في الاعتبار عند حساب استخدام القرص الحالي.

يتحكم SystemMaxUse= و RuntimeMaxUse= في مقدار مساحة القرص التي قد تستخدمها اليومية كحد أقصى. يتحكم SystemKeepFree= و RuntimeKeepFree= في مقدار مساحة القرص التي يجب أن يتركها systemd-journald حرة للاستخدامات الأخرى. سيحترم systemd-journald كلا الحدين ويستخدم القيمة الأصغرمن القيمتين.

الزوج الأول يبلغ مبدئيًا 10% والثاني 15% من حجم نظام الملفات المعني، لكن كل قيمة مبدئية محسوبة محدودة بـ 4G. إذا كان نظام الملفات ممتلئًا تقريبًا وتم انتهاك إما SystemKeepFree= أو RuntimeKeepFree= عند بدء تشغيل systemd-journald، سيتم رفع الحد إلى النسبة المئوية الفعلية الحرة. هذا يعني أنه إذا كانت هناك مساحة حرة كافية من قبل وتم إنشاء ملفات اليوميات، ثم تسبب شيء آخر في امتلاء نظام الملفات، سيتوقف journald عن استخدام مساحة أكبر، لكنه لن يقوم بإزالة الملفات الموجودة لتقليل البصمة مرة أخرى. لاحظ أيضًا أنه يتم حذف الملفات المؤرشفة فقط لتقليل المساحة التي تشغلها ملفات اليوميات. هذا يعني أنه، في الواقع، قد لا تزال هناك مساحة مستخدمة أكثر من حد SystemMaxUse= أو RuntimeMaxUse= بعد اكتمال عملية التنظيف.

يتحكم SystemMaxFileSize= و RuntimeMaxFileSize= في أقصى حجم يمكن أن تصل إليه ملفات اليوميات الفردية. يؤثر هذا على دقة توفر مساحة القرص من خلال التدوير، أي حذف البيانات التاريخية. المبدئي هو ثمن القيم المكونة مع SystemMaxUse= و RuntimeMaxUse= محدود بـ 128M، بحيث يتم عادةً الاحتفاظ بسبعة ملفات يوميات مدورة كتاريخ. إذا تم تمكين وضع الضغط لليوميات (مفعل مبدئيًا)، يكون الحد الأقصى لحجم الملف محدودًا بـ 4G.

حدد القيم بالبايت أو استخدم K، M، G، T، P، E كوحدات للأحجام المحددة (تساوي 1024، 1024²، ... بايت). لاحظ أنه يتم فرض حدود الحجم بشكل متزامن عند تمديد ملفات اليوميات، ولا حاجة لخطوة تدوير صريحة يطلقها الوقت.

يتحكم SystemMaxFiles= و RuntimeMaxFiles= في عدد ملفات اليوميات الفردية التي يجب الاحتفاظ بها كحد أقصى. لاحظ أنه يتم حذف الملفات المؤرشفة فقط لتقليل عدد الملفات حتى يتم الوصول إلى هذا الحد؛ ستبقى الملفات النشطة موجودة. هذا يعني أنه، في الواقع، قد لا يزال هناك عدد أكبر من ملفات اليوميات إجمالاً من هذا الحد بعد اكتمال عملية التنظيف. هذا الإعداد يبلغ مبدئيًا 100.

الحد الأقصى للوقت لتخزين الإدخالات في ملف يوميات واحد قبل التدوير إلى الملف التالي. عادةً، لا ينبغي أن يكون التدوير المستند إلى الوقت مطلوبًا حيث أن التدوير المستند إلى الحجم مع خيارات مثل SystemMaxFileSize= يجب أن يكون كافيًا لضمان عدم نمو ملفات اليوميات بدون حدود. ومع ذلك، لضمان عدم فقدان الكثير من البيانات دفعة واحدة عند حذف ملفات اليوميات القديمة، قد يكون من المنطقي تغيير هذه القيمة من المبدئي وهو شهر واحد. اضبط على 0 لتعطيل هذه الميزة. يقبل هذا الإعداد قيم الوقت التي قد تُلحق بالوحدات "year"، "month"، "week"، "day"، "h" أو "m" لتجاوز وحدة الوقت المبدئية وهي الثواني.

أُضيف في الإصدارة 195.

الحد الأقصى للوقت لتخزين إدخالات اليوميات. يتحكم هذا في ما إذا كانت ملفات اليوميات التي تحتوي على إدخالات أقدم من الفترة الزمنية المحددة سيتم حذفها. عادةً، لا ينبغي أن يكون الحذف المستند إلى الوقت لملفات اليوميات القديمة مطلوبًا حيث أن الحذف المستند إلى الحجم مع خيارات مثل SystemMaxUse= يجب أن يكون كافيًا لضمان عدم نمو ملفات اليوميات بدون حدود. ومع ذلك، لفرض سياسات الاحتفاظ بالبيانات، قد يكون من المنطقي تغيير هذه القيمة من المبدئي وهو 0 (الذي يعطل هذه الميزة). يقبل هذا الإعداد أيضًا قيم الوقت التي قد تُلحق بالوحدات "year"، "month"، "week"، "day"، "h" أو " m" لتجاوز وحدة الوقت المبدئية وهي الثواني.

أُضيف في الإصدارة 195.

المهلة قبل مزامنة ملفات اليوميات على القرص. بعد المزامنة، توضع ملفات اليوميات في حالة OFFLINE. لاحظ أن المزامنة تتم دون قيد أو شرط فورًا بعد تسجيل رسالة سجل ذات أولوية CRIT أو ALERT أو EMERG. لذلك ينطبق هذا الإعداد فقط على رسائل المستويات ERR، WARNING، NOTICE، INFO، DEBUG. المهلة المبدئية هي 5 دقائق.

أُضيف في الإصدارة 199.

تحكم في ما إذا كانت رسائل السجل التي يتلقاها برنامج خفي اليوميات يجب إعادة توجيهها إلى برنامج خفي syslog تقليدي، أو إلى مخزن مؤقت لسجل النواة (kmsg)، أو إلى وحدة التحكم في النظام، أو إرسالها كرسائل حائط لجميع المستخدمين المسجلين الدخول، أو إرسالها عبر مقبس. تقبل هذه الخيارات وسائط منطقية باستثناء "ForwardToSocket=" الذي يقبل عنوانًا بدلاً من ذلك. إذا تم تمكين إعادة التوجيه إلى syslog ولكن لا شيء يقرأ الرسائل من المقبس، فلن يكون لإعادة التوجيه إلى syslog أي تأثير. مبدئيًا، يتم تمكين إعادة التوجيه إلى الحائط فقط. يمكن تجاوز هذه الإعدادات في وقت الإقلاع باستخدام خيارات سطر أوامر النواة "systemd.journald.forward_to_syslog"، "systemd.journald.forward_to_kmsg"، "systemd.journald.forward_to_console"، و "systemd.journald.forward_to_wall". إذا تم تحديد اسم الخيار بدون "=" والوسيطة التالية، يُفترض أن تكون القيمة true. وإلا، يتم تحليل الوسيطة كقيمة منطقية.

يمكن تحديد عنوان إعادة توجيه المقبس باستخدام بيانات الاعتماد "journal.forward_to_socket". أنواع المقابس التالية مدعومة:

AF_INET (e.g. "192.168.0.11:4444"), AF_INET6 (e.g. "[2001:db8::ff00:42:8329]:4444"), AF_UNIX (e.g. "/run/host/journal/socket"), AF_VSOCK (e.g. "vsock:2:1234")

عند إعادة التوجيه إلى وحدة التحكم، يمكن تغيير TTY للتسجيل باستخدام TTYPath=، الموضح أدناه.

عند إعادة التوجيه إلى المخزن المؤقت لسجل النواة (kmsg)، تأكد من تحديد حجم كبير مناسب للمخزن المؤقت للسجل، على سبيل المثال بإضافة "log_buf_len=8M" إلى سطر أوامر النواة. سيقوم systemd آليًا بتعطيل تحديد معدل النواة المطبق على عمليات مساحة المستخدم (المكافئ لتعيين "printk.devkmsg=on").

عند إعادة التوجيه عبر مقبس، يتم استخدام تنسيق تصدير اليوميات[4] عند الإرسال عبر الشبكة. بشكل ملحوظ، يتضمن هذا حقل البيانات الوصفية __REALTIME_TIMESTAMP بحيث يمكن استخدام systemd-journal-remote (انظر systemd-journal-remote.service(8)) لاستقبال إدخالات اليوميات المعاد توجيهها.

ملاحظة: يتم إجراء إعادة التوجيه بشكل متزامن داخل journald، وقد يؤثر بشكل كبير على أدائه. هذا ذو صلة خاصة عند استخدام ForwardToConsole=yes في بيئات السحابة، حيث تكون وحدة التحكم غالبًا منفذًا تسلسليًا افتراضيًا بطيئًا. نظرًا لأن journald مطبق كبرنامج خفي تقليدي أحادي العملية، فإن إعادة التوجيه إلى وحدة تحكم معلقة تمامًا ستحظر journald. يمكن أن يكون لهذا تأثير متتالي يؤدي إلى حظر أي خدمات تسجل بشكل متزامن في اليوميات المحظورة أيضًا. ما لم يتم تصحيح/تطوير شيء بنشاط، فمن الأفضل عمومًا إعداد خدمة من نمط journalctl --follow معاد توجيهها إلى وحدة التحكم، بدلاً من ForwardToConsole=yes، للاستخدام الإنتاجي.

ملاحظة: استخدام ForwardToSocket= عبر روابط IPv4/IPv6 يمكن أن يكون بطيئًا جدًا بسبب الطبيعة المتزامنة للمقابس. احرص على ضمان أن رابطك هو رابط محلي منخفض الكمون إذا أمكن. عادةً، لا تتوفر شبكات IP في كل مكان يعمل فيه journald، على سبيل المثال في initrd أثناء الإقلاع. فكر في استخدام مقابس AF_VSOCK/AF_UNIX لهذا إذا أمكن.

يتحكم في الحد الأقصى لمستوى تسجيل الرسائل التي يتم تخزينها في السجل، أو إعادة توجيهها إلى syslog أو kmsg أو وحدة التحكم أو شاشة العرض أو منفذ اتصال (في حال تم تمكينه، انظر أعلاه). كحجة، يأخذ أحد القيم التالية: ”emerg“، ”alert“، ’crit‘، ”err“، ”warning“، ”notice“، ”info“، ”debug“، أو قيم عددية في النطاق من 0–7 (المقابلة لنفس المستويات). يتم تخزين/إعادة توجيه الرسائل التي تساوي أو تقل عن مستوى السجل المحدد، ويتم تجاهل الرسائل التي تزيد عنه. القيمة الافتراضية هي ”debug“ لـ MaxLevelStore=، MaxLevelSyslog= و MaxLevelSocket=، لضمان تخزين جميع الرسائل في السجل، وإعادة توجيهها إلى syslog والمقبس إن وجد . الافتراضي هو ”notice“ لـ MaxLevelKMsg، و”info“ لـ MaxLevelConsole، و”emerg“ لـ MaxLevelWall. يمكن تجاوز هذه الإعدادات عند وقت التشغيل باستخدام خيارات سطر أوامر النواة ”systemd.journald.max_level_store=“، و"systemd.journald.max_level_syslog=”، و“systemd.journald.max_level_kmsg="، و”systemd.journald.max_level_console=“، و"systemd.journald.max_level_wall=”, “systemd.journald.max_level_socket=".

أُضيف في الإصدار 185.

يأخذ قيمة منطقية. إذا تم تمكينه، يقوم systemd-journal بمعالجة رسائل /dev/kmsg التي يولدها النواة. في مساحة اسم السجل الافتراضية، يكون هذا الخيار ممكّنًا بشكل افتراضي، بينما يكون معطلاً في جميع المساحات الأخرى.

أُضيف في الإصدارة 235.

يستقبل قيمة منطقية أو القيمة الخاصة ”keep“. في حالة التفعيل، سيقوم systemd-journald بتشغيل تدقيق النواة عند بدء التشغيل. وفي حالة التعطيل، سيقوم بإيقاف تشغيله. عند ”keep“، لن يُفعّلها أو يُعطلها، تاركًا الحالة السابقة دون تغيير. هذا يعني أنه إذا قامت أداة أخرى بتشغيل التدقيق حتى لو تركه systemd-journald معطلاً، فسيظل يجمع الرسائل المُنشأة. القيمة المبدئية هي yes في مساحة اسم السجل المبدئي، و”keep“ بخلاف ذلك.

يرجى ملاحظة أن هذا الخيار لا يتحكم في ما إذا كان systemd-journald يجمع سجلات التدقيق المُنشأة، بل يقتصر دوره على توجيه النواة لإنشائها. إذا كنت بحاجة إلى منع systemd-journald من جمع الرسائل المُنشأة، فيمكن تعطيل وحدة المقبس ”systemd-journald-audit.socket“، وفي هذه الحالة، لن يكون لهذا الإعداد أي تأثير.

أُضيف في الإصدار 246.

تغيير جهاز TTY الخاص بوحدة التحكم المراد استخدامه في حالة استخدام ForwardToConsole=yes.القيمة المبدئية هي /dev/console.

أُضيف في الإصدار 185.

الحد الأقصى لطول السطر المسموح به عند تحويل سجلات التدفق إلى سجلات سجلات. عندما تكون وحدة systemdu0645]خرجات/أخطاء Aq القياسية) متصلة بالمجلة عبر مقبس تدفق، تُقسم البيانات المقروءة إلى سجلات سجلات فردية عند أحرف نهاية السطر (”\n“، ASCII 10) و NUL. إذا لم يُقرأ مثل هذا الفاصل لعدد البايتات المحدد، يضاف حد سجل ثابت بشكل مصطنع، مما يقسم الأسطر الطويلة جدًا إلى سجلات سجل متعددة. يؤدي اختيار قيم كبيرة جدًا إلى زيادة استخدام الذاكرة المحتمل لبرنامج Journal الخفي لكل عميل دفق، حيث في أسوأ الحالات يحتاج برنامج Journal الخفي إلى تخزين العدد المحدد من البايتات مؤقتًا في الذاكرة قبل أن يتمكن من مسح سجل سجل جديد إلى القرص. لاحظ أيضًا أن السماح بأطوال سطور قصوى كبيرة جدًا يؤثر على التوافق مع بروتوكولات السجل التقليدية حيث قد لا تتسع سجلات السجل بعد الآن في مخطط بيانات AF_UNIX أو AF_INET واحد. يأخذ حجمًا بالبايت. إذا كانت القيمة مسبوقة بـ K أو M أو G أو T، يتم تحليل الحجم المحدد على أنه كيلوبايت أو ميغابايت أو جيجابايت أو تيرابايت (بأساس 1024)، على التوالي. القيمة المبدئية هي 48 كيلوبايت، وهي كبيرة نسبيًا ولكنها لا تزال صغيرة بما يكفي بحيث تتناسب سجلات السجلات على الأرجح مع مخططات بيانات الشبكة مع مساحة إضافية للبيانات الوصفية. لاحظ أن القيم الأقل من 79 غير مقبولة و سترتفع إلى 79.

أُضيف في الإصدارة 235.