/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 (که در صورت نیاز ایجاد می‌شود) ذخیره می‌گردند، به همراه بازگشت خودکار (fallback) به /run/log/journal (که در صورت نیاز ایجاد می‌شود) در اوایل فرآیند بوت و در صورتی که دیسک قابل نوشتن نباشد. مقدار "auto" اگر دایرکتوری /var/log/journal وجود داشته باشد مشابه "persistent" رفتار می‌کند، و در غیر این صورت مانند "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.

یک مقدار بولی می‌پذیرد. اگر فعال باشد (حالت پیش‌فرض)، شیءهای داده‌ای که باید در ژورنال ذخیره شوند و بزرگ‌تر از آستانه پیش‌فرض ۵۱۲ بایت هستند، پیش از نوشته شدن بر روی سیستم فایل فشرده می‌شوند. همچنین می‌توان آن را بر روی تعداد بایت‌ها تنظیم کرد تا آستانه فشرده‌سازی مستقیماً مشخص شود. پسوندهایی مانند K، M، و G می‌توانند برای تعیین واحدهای بزرگ‌تر استفاده شوند.

یک مقدار بولی می‌پذیرد. اگر فعال باشد (حالت پیش‌فرض)، و کلید مهر و موم در دسترس باشد (که توسط دستور --setup-keys در journalctl(1) ایجاد می‌شود)، قابلیت مهر و موم امن رو به جلو (Forward Secure Sealing یا FSS) برای تمامی فایل‌های پایدار ژورنال فعال می‌گردد. قابلیت FSS بر پایه Seekable Sequential Key Generators[2] توسط G. A. Marson و B. Poettering (شناسه دیجیتال doi:10.1007/978-3-642-40203-6_7) ارائه شده است و می‌تواند برای محافظت از فایل‌های ژورنال در برابر تغییرات نامحسوس استفاده شود.

افزوده‌شده در نسخه 189.

کنترل می‌کند که آیا فایل‌های ژورنال به ازای هر کاربر تفکیک شوند یا خیر، که یکی از دو مقدار "uid" یا "none" است. فایل‌های ژورنال تفکیک‌شده در درجه اول برای کنترل دسترسی مفید هستند: در یونیکس/لینوکس کنترل دسترسی به ازای هر فایل مدیریت می‌شود و دیمن ژورنال به کاربران دسترسی خواندن فایل‌های ژورنال مربوط به خودشان را واگذار می‌کند. اگر "uid" باشد، تمام کاربران عادی (با UID خارج از محدوده کاربران سیستمی، کاربران سرویس پویا، و کاربر nobody) هر کدام فایل‌های ژورنال اختصاصی خود را دریافت می‌کنند، و کاربران سیستمی در ژورنال سیستم لاگ ثبت خواهند کرد. برای جزئیات بیشتر درباره محدوده‌های UID، Users, Groups, UIDs and GIDs on systemd systems[3] را ببینید. اگر "none" باشد، فایل‌های ژورنال بر اساس کاربر تفکیک نمی‌شوند و تمامی پیام‌ها در ژورنال واحد سیستمی ذخیره می‌گردند. در این حالت، کاربران غیرممتاز عموماً به داده‌های لاگ خود دسترسی ندارند. توجه داشته باشید که تفکیک فایل‌های ژورنال بر اساس کاربر تنها برای ژورنال‌هایی در دسترس است که به صورت پایدار ذخیره شده‌اند. اگر ژورنال‌ها بر روی فضای ذخیره‌سازی فرّار ذخیره شده باشند (گزینه Storage= در بالا را ببینید)، تنها یک فایل ژورنال واحد استفاده می‌شود. مقدار پیش‌فرض "uid" است.

افزوده‌شده در نسخه 190.

محدودسازی نرخ ارسال پیام (rate limiting) را که بر تمامی پیام‌های تولیدشده در سیستم اعمال می‌شود پیکربندی می‌کند. اگر در بازه زمانی تعیین‌شده با RateLimitIntervalSec=، تعداد پیام‌های بیشتری نسبت به آنچه در RateLimitBurst= مشخص شده است توسط یک سرویس ثبت شود، تمامی پیام‌های بعدی در همان بازه تا پایان یافتن بازه زمانی دور ریخته می‌شوند. پیامی درباره تعداد پیام‌های دور ریخته‌شده تولید خواهد شد. این محدودسازی نرخ به ازای هر سرویس اعمال می‌شود، به‌طوری که دو سرویس ثبت‌کننده لاگ در محدودیت‌های یکدیگر تداخل ایجاد نمی‌کنند. مقدار پیش‌فرض ۱۰۰۰۰ پیام در ۳۰ ثانیه است. زمان برای RateLimitIntervalSec= می‌تواند در واحدهای زیر مشخص شود: "s"، "min"، "h"، "ms"، "us". برای غیرفعال کردن هر نوع محدودسازی نرخ، هر یک از مقادیر را روی ۰ قرار دهید.

توجه داشته باشید که نرخ مؤثر محدودسازی در ضریبی که از فضای دیسک آزاد در دسترس برای ژورنال به دست می‌آید ضرب می‌شود. در حال حاضر، این ضریب با استفاده از لگاریتم بر مبنای ۲ محاسبه می‌شود.

جدول 1. نمونه تغییرات نرخ RateLimitBurst= بر اساس فضای دیسک در دسترس

Available Disk Space	Burst Multiplier
<= 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/ سوار (mount) شده باشد، قابل نوشتن باشد، و دایرکتوری /var/log/journal وجود داشته باشد. در غیر این صورت، تنها مورد دوم اعمال می‌شود. توجه داشته باشید که این بدان معناست که در اوایل فرآیند بوت و در صورتی که مدیر سیستم ثبت پایدار لاگ را غیرفعال کرده باشد، تنها گزینه‌های دوم اعمال خواهند شد؛ در حالی که اگر ثبت پایدار لاگ فعال باشد و سیستم به طور کامل بوت شده باشد، گزینه‌های اول اعمال می‌گردند. journalctl و systemd-journald تمام فایل‌هایی را که نام آن‌ها به ".journal" یا ".journal~" ختم نمی‌شود نادیده می‌گیرند، بنابراین تنها چنین فایل‌هایی که در پوشه‌های مربوطه قرار دارند در محاسبه میزان مصرف فعلی دیسک در نظر گرفته می‌شوند.

گزینه‌های SystemMaxUse= و RuntimeMaxUse= کنترل می‌کنند که ژورنال حداکثر چقدر از فضای دیسک را می‌تواند مصرف کند. SystemKeepFree= و RuntimeKeepFree= کنترل می‌کنند که systemd-journald چقدر از فضای دیسک را باید برای سایر مصارف خالی نگه دارد. systemd-journald به هر دو محدودیت پایبند خواهد بود و از مقدار کوچک‌تر میان این دو استفاده می‌کند.

جفت اول به طور پیش‌فرض ۱۰٪ و جفت دوم ۱۵٪ از اندازه سیستم فایل مربوطه را استفاده می‌کنند، اما هر یک از مقادیر پیش‌فرض محاسبه‌شده حداکثر به 4G محدود می‌شوند. اگر سیستم فایل تقریباً پر باشد و هر یک از محدودیت‌های SystemKeepFree= یا RuntimeKeepFree= در زمان شروع systemd-journald نقض شده باشند، این حد به همان درصدی که در واقع آزاد است افزایش می‌یابد. این بدان معناست که اگر قبلاً فضای خالی کافی وجود داشته و فایل‌های ژورنال ایجاد شده باشند، و متعاقباً عامل دیگری باعث پر شدن سیستم فایل شود، journald مصرف فضای بیشتر را متوقف خواهد کرد، اما فایل‌های موجود را برای کاهش ردپای خود حذف نخواهد کرد. همچنین توجه داشته باشید که تنها فایل‌های بایگانی‌شده حذف می‌شوند تا فضای اشغال‌شده توسط فایل‌های ژورنال کاهش یابد. این بدان معنی است که در عمل، ممکن است حتی پس از پایان عملیات پاکسازی (vacuuming)، فضای استفاده‌شده بیشتر از حد مجاز SystemMaxUse= یا RuntimeMaxUse= باشد.

گزینه‌های SystemMaxFileSize= و RuntimeMaxFileSize= کنترل می‌کنند که فایل‌های ژورنال تکی حداکثر تا چه اندازه‌ای می‌توانند رشد کنند. این موضوع بر دقت آزادسازی فضای دیسک از طریق چرخش لاگ (rotation)، یعنی حذف داده‌های قدیمی، تأثیر می‌گذارد. مقدار پیش‌فرض یک‌هشتم مقادیر پیکربندی‌شده با SystemMaxUse= و RuntimeMaxUse= است که حداکثر به 128M محدود می‌شود، به طوری که معمولاً هفت فایل ژورنال چرخیده‌شده به عنوان تاریخچه نگهداری می‌شوند. اگر حالت فشرده ژورنال فعال باشد (که به طور پیش‌فرض فعال است)، حداکثر اندازه فایل به 4G محدود می‌گردد.

مقادیر را بر حسب بایت مشخص کنید یا از K، M، G، T، P، E به عنوان واحد برای اندازه‌های مشخص‌شده استفاده نمایید (معادل با ۱۰۲۴، ۱۰۲۴ به توان ۲، الی آخر بایت). توجه داشته باشید که محدودیت‌های اندازه به صورت همزمان با افزایش اندازه فایل‌های ژورنال اعمال می‌شوند و نیازی به گام چرخش صریح بر اساس زمان نیست.

گزینه‌های SystemMaxFiles= و RuntimeMaxFiles= کنترل می‌کنند که حداکثر چه تعداد فایل ژورنال تکی نگهداری شود. توجه داشته باشید که برای کاهش تعداد فایل‌ها تا رسیدن به این محدودیت، تنها فایل‌های بایگانی‌شده حذف می‌شوند؛ فایل‌های فعال همچنان باقی خواهند ماند. این بدان معناست که در عمل، حتی پس از اتمام عملیات پاکسازی ممکن است مجموع فایل‌های ژورنال موجود از این محدودیت بیشتر باشد. این تنظیم به طور پیش‌فرض برابر با ۱۰۰ است.

حداکثر زمان برای ذخیره مدخل‌ها در یک فایل ژورنال تکی پیش از چرخش به فایل بعدی. به طور معمول، چرخش بر اساس زمان نباید مورد نیاز باشد، چرا که چرخش بر اساس اندازه با گزینه‌هایی مانند SystemMaxFileSize= باید برای اطمینان از این‌که فایل‌های ژورنال بدون محدودیت رشد نمی‌کنند کافی باشد. با این حال، برای اطمینان از این‌که هنگام حذف فایل‌های ژورنال قدیمی، داده‌های بسیار زیادی به یک‌باره از دست نرود، ممکن است تغییر این مقدار از مقدار پیش‌فرض یک ماه منطقی باشد. برای غیرفعال کردن این ویژگی، آن را روی ۰ تنظیم کنید. این تنظیم مقادیر زمانی را می‌پذیرد که می‌توانند دارای پسوند واحدهای "year"، "month"، "week"، "day"، "h" یا "m" باشند تا واحد زمانی پیش‌فرض ثانیه را بازنویسی نمایند.

افزوده‌شده در نسخه 195.

حداکثر زمان برای نگهداری مدخل‌های ژورنال. این گزینه کنترل می‌کند که آیا فایل‌های ژورنال حاوی مدخل‌های قدیمی‌تر از بازه زمانی مشخص‌شده حذف شوند یا خیر. به طور معمول، حذف فایل‌های ژورنال قدیمی بر اساس زمان نباید لازم باشد چرا که حذف بر اساس اندازه با گزینه‌هایی مانند SystemMaxUse= باید برای اطمینان از این‌که فایل‌های ژورنال بدون محدودیت رشد نمی‌کنند کافی باشد. با این حال، برای اعمال سیاست‌های نگهداری داده‌ها (data retention)، ممکن است تغییر این مقدار از مقدار پیش‌فرض ۰ (که این ویژگی را غیرفعال می‌کند) منطقی باشد. این تنظیم نیز مقادیر زمانی را می‌پذیرد که می‌توانند دارای پسوند واحدهای "year"، "month"، "week"، "day"، "h" یا "m" باشند تا واحد زمانی پیش‌فرض ثانیه را بازنویسی کنند.

افزوده‌شده در نسخه 195.

مدت‌زمان انتظار پیش از همگام‌سازی (sync) فایل‌های ژورنال بر روی دیسک. پس از همگام‌سازی، فایل‌های ژورنال در وضعیت OFFLINE قرار می‌گیرند. توجه داشته باشید که همگام‌سازی بلافاصله پس از ثبت یک پیام لاگ با اولویت CRIT، ALERT یا EMERG بدون قید و شرط انجام می‌شود. بنابراین این تنظیم تنها برای پیام‌هایی با سطوح ERR، WARNING، NOTICE، INFO، DEBUG اعمال می‌شود. مدت‌زمان پیش‌فرض ۵ دقیقه است.

افزوده‌شده در نسخه 199.

کنترل می‌کند که آیا پیام‌های لاگ دریافت‌شده توسط دیمن ژورنال باید به یک دیمن سنتی syslog، به بافر لاگ هسته (kmsg)، به کنسول سیستم، به عنوان پیام‌های wall به تمامی کاربران واردشده به سیستم فرستاده شوند یا بر روی یک سوکت ارسال گردند. این گزینه‌ها آرگومان‌های بولی می‌پذیرند، به جز "ForwardToSocket=" که به جای آن یک آدرس دریافت می‌کند. اگر بازفرستادن به syslog فعال باشد اما هیچ برنامه‌ای پیام‌ها را از سوکت نخواند، بازفرستادن به syslog هیچ اثری نخواهد داشت. به طور پیش‌فرض، تنها بازفرستادن به wall فعال است. این تنظیمات ممکن است در زمان بوت با گزینه‌های خط فرمان هسته "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 (مانند "192.168.0.11:4444")، AF_INET6 (مانند "[2001:db8::ff00:42:8329]:4444")، AF_UNIX (مانند "/run/host/journal/socket")، AF_VSOCK (مانند "vsock:2:1234")

هنگام بازفرستادن به کنسول، TTY مورد استفاده برای ثبت لاگ را می‌توان با TTYPath= که در زیر شرح داده شده تغییر داد.

هنگام بازفرستادن به بافر لاگ هسته (kmsg)، اطمینان حاصل کنید که اندازه مناسبی برای بافر لاگ انتخاب کرده‌اید، برای نمونه با افزودن "log_buf_len=8M" به خط فرمان هسته. systemd به طور خودکار محدودسازی نرخ هسته را که بر فرایندهای فضای کاربری اعمال می‌شود غیرفعال خواهد کرد (معادل با تنظیم "printk.devkmsg=on").

هنگام بازفرستادن بر روی یک سوکت، Journal Export Format[4] در هنگام ارسال بر روی شبکه استفاده می‌شود. به‌ویژه این فرمت شامل فیلد فراداده __REALTIME_TIMESTAMP است تا systemd-journal-remote (ببینید systemd-journal-remote.service(8)) بتواند برای دریافت مدخل‌های بازفرستاده‌شده ژورنال استفاده شود.

نکته: بازفرستادن در داخل journald به صورت همگام (synchronous) انجام می‌شود، و ممکن است عملکرد آن را به طور چشمگیری تحت تأثیر قرار دهد. این موضوع به ویژه هنگام استفاده از ForwardToConsole=yes در محیط‌های ابری صادق است، جایی که کنسول اغلب یک پورت سریال مجازی و کند است. از آنجا که journald به عنوان یک دیمن تک‌فرآیندی سنتی پیاده‌سازی شده است، بازفرستادن به کنسولی که کاملاً قفل کرده است journald را مسدود خواهد کرد. این موضوع می‌تواند اثر آبشاری داشته باشد و منجر به مسدود شدن تمام سرویس‌هایی شود که به صورت همگام در ژورنالِ مسدودشده لاگ ثبت می‌کنند. مگر در مواردی که فعالانه در حال اشکال‌زدایی یا توسعه هستید، عموماً ترجیح داده می‌شود برای استفاده در محیط‌های عملیاتی به جای ForwardToConsole=yes، سرویسی با الگوی journalctl --follow تنظیم شود که خروجی آن به کنسول هدایت شده باشد.

نکته: استفاده از ForwardToSocket= بر روی اتصالات IPv4/IPv6 می‌تواند به دلیل ماهیت همگام سوکت‌ها بسیار کند باشد. در صورت امکان دقت کنید که اتصال شما یک پیوند محلی با تاخیر کم باشد. معمولاً شبکه IP در همه جاهایی که journald اجرا می‌شود، به عنوان نمونه در initrd در حین بوت، در دسترس نیست. در صورت امکان استفاده از سوکت‌های AF_VSOCK/AF_UNIX را برای این منظور در نظر بگیرید.

حداکثر سطح لاگ پیام‌هایی را که در ژورنال ذخیره می‌شوند، به syslog، kmsg، کنسول، wall، یا یک سوکت بازفرستاده می‌شوند (در صورتی که فعال باشد، بالا را ببینید) کنترل می‌کند. به عنوان آرگومان، یکی از مقادیر "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 حسابرسی هسته (kernel auditing) را در زمان شروع به کار فعال خواهد کرد. اگر غیرفعال باشد، آن را خاموش می‌کند. در صورت تنظیم روی "keep"، آن را نه فعال و نه غیرفعال می‌کند، و وضعیت قبلی را بدون تغییر رها می‌سازد. این بدان معناست که اگر ابزار دیگری حسابرسی را فعال کند، حتی اگر systemd-journald آن را خاموش گذاشته باشد، همچنان پیام‌های تولیدشده را جمع‌آوری خواهد کرد. مقدار پیش‌فرض در فضای نام پیش‌فرض ژورنال yes است و در غیر این صورت "keep" می‌باشد.

توجه داشته باشید که این گزینه جمع‌آوری رکوردهای حسابرسی تولیدشده توسط systemd-journald را کنترل نمی‌کند، بلکه تنها این را کنترل می‌کند که آیا به هسته اعلام کند آن‌ها را تولید کند یا خیر. اگر نیاز دارید مانع از جمع‌آوری پیام‌های تولیدشده توسط systemd-journald شوید، واحد سوکت "systemd-journald-audit.socket" می‌تواند غیرفعال شود که در این حالت، این تنظیم بدون اثر خواهد بود.

افزوده‌شده در نسخه 246.

در صورتی که ForwardToConsole=yes استفاده شده باشد، کنسول TTY مورد استفاده را تغییر می‌دهد. مقدار پیش‌فرض /dev/console است.

افزوده‌شده در نسخه 185.

حداکثر طول مجاز خط را هنگام تبدیل لاگ‌های جریانی به لاگ‌های رکوردی تعیین می‌کند. هنگامی که خروجی استاندارد/خطای استاندارد یک واحد systemd از طریق یک سوکت جریانی به ژورنال متصل می‌شود، داده‌های خوانده‌شده در محل خط جدید ("\n"، کد اسکی ۱۰) و نویسه‌های NUL به رکوردهای لاگ مجزا تفکیک می‌شوند. اگر برای تعداد بایت‌های مشخص‌شده چنین جداکننده‌ای خوانده نشود، یک مرز رکورد لاگ سخت به صورت مصنوعی درج می‌شود که خطوط بیش از حد طولانی را به چندین رکورد لاگ تقسیم می‌کند. انتخاب مقادیر بسیار بزرگ، مصرف حافظه احتمالی دیمن ژورنال را برای هر کلاینت جریانی افزایش می‌دهد، زیرا در بدترین حالت دیمن ژورنال باید تعداد بایت‌های مشخص‌شده را پیش از انتقال رکورد جدید به دیسک در حافظه بافر کند. همچنین توجه داشته باشید که مجاز کردن طول خطوط بیش از حد طولانی بر سازگاری با پروتکل‌های سنتی لاگ تأثیر می‌گذارد زیرا ممکن است رکوردهای لاگ دیگر در یک دیتاگرام تکی AF_UNIX یا AF_INET جا نشوند. یک اندازه بر حسب بایت می‌پذیرد. اگر مقدار دارای پسوند K، M، G یا T باشد، اندازه مشخص‌شده به ترتیب به صورت کیلوبایت، مگابایت، گیگابایت یا ترابایت (بر مبنای ۱۰۲۴) محاسبه می‌شود. مقدار پیش‌فرض 48K است، که نسبتاً بزرگ است اما هنوز به اندازه کافی کوچک است تا رکوردهای لاگ به احتمال زیاد در کنار فضای اضافه برای فراداده در دیتاگرام‌های شبکه جا شوند. توجه داشته باشید که مقادیر کمتر از ۷۹ پذیرفته نمی‌شوند و به ۷۹ افزایش می‌یابند.

افزوده‌شده در نسخه 235.