SYSTEMD-JOURNALD.SERVICE(8) systemd-journald.service SYSTEMD-JOURNALD.SERVICE(8)

systemd-journald.service, systemd-journald.socket, systemd-journald-dev-log.socket, systemd-journald-audit.socket, systemd-journald@.service, systemd-journald@.socket, systemd-journald-varlink@.socket, systemd-journald - سرویس ژورنال

systemd-journald.service
systemd-journald.socket
systemd-journald-dev-log.socket
systemd-journald-audit.socket
systemd-journald@.service
systemd-journald@.socket
systemd-journald-varlink@.socket
/usr/lib/systemd/systemd-journald

systemd-journald یک سرویس سیستمی است که داده‌های ثبت لاگ را جمع‌آوری و ذخیره می‌کند. این سرویس بر اساس اطلاعات ثبت لاگ دریافت‌شده از منابع گوناگون، ژورنال‌های ساخت‌یافته و نمایه‌سازی‌شده را ایجاد و نگهداری می‌نماید:

•پیام‌های لاگ هسته، از طریق kmsg
•پیام‌های ساده لاگ سیستم، از طریق فراخوانی syslog(3) در libc
•پیام‌های ساخت‌یافته لاگ سیستم از طریق رابط برنامه‌نویسی بومی ژورنال (native Journal API)، sd_journal_print(3) و Native Journal Protocol[1] را ببینید
•خروجی استاندارد و خطای استاندارد واحدهای سرویس. برای جزئیات بیشتر به بخش زیر مراجعه کنید.
•رکوردهای حسابرسی، برگرفته از زیرسیستم حسابرسی هسته

دیمن به‌طور ضمنی فیلدهای فرادادهٔ متعددی را برای هر پیام لاگ به شیوه‌ای امن و غیرقابل جعل جمع‌آوری می‌کند. برای اطلاعات بیشتر درباره فراداده‌های جمع‌آوری‌شده به systemd.journal-fields(7) مراجعه کنید.

داده‌های لاگ جمع‌آوری‌شده توسط ژورنال اساساً مبتنی بر متن هستند، اما در صورت نیاز می‌توانند شامل داده‌های باینری نیز باشند. اندازهٔ هر یک از فیلدهای تشکیل‌دهندهٔ یک رکورد لاگ ذخیره‌شده در ژورنال می‌تواند تا 2⁶⁴-1 بایت باشد.

سرویس ژورنال داده‌های لاگ را یا به‌صورت پایدار در /var/log/journal و یا به‌صورت فرّار در /run/log/journal/ ذخیره می‌کند (در حالت دوم، داده‌ها هنگام راه‌اندازی مجدد سیستم از بین می‌روند). به‌طور پیش‌فرض، اگر در حین بوت /var/log/journal/ وجود داشته باشد، داده‌های لاگ به‌صورت پایدار ذخیره می‌شوند، در غیر این صورت به‌طور ضمنی به ذخیره‌سازی فرّار بازمی‌گردد. از Storage= در journald.conf(5) برای پیکربندی محل قرارگیری داده‌های لاگ، مستقل از وجود داشتن /var/log/journal/ استفاده کنید.

توجه داشته باشید که journald در ابتدا از ذخیره‌سازی فرّار استفاده می‌کند، تا زمانی که فراخوانی journalctl --flush (یا ارسال SIGUSR1 به journald) موجب شود تا به ثبت لاگ پایدار تغییر وضعیت دهد (تحت شرایط ذکرشده در بالا). این عمل در زمان بوت به‌طور خودکار از طریق "systemd-journal-flush.service" انجام می‌شود.

در سیستم‌هایی که /var/log/journal/ هنوز در آن‌ها وجود ندارد اما ثبت لاگ پایدار مورد نظر است (و از journald.conf پیش‌فرض استفاده می‌شود)، کافی است این دایرکتوری ایجاد شده و از درستی حالت‌های دسترسی و مالکیت آن اطمینان حاصل گردد:

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

برای اطلاعات درباره پیکربندی این سرویس به journald.conf(5) مراجعه کنید.

مدیر سرویس systemd به‌طور پیش‌فرض تمامی فرایندهای سرویس را در حالی فراخوانی می‌کند که خروجی استاندارد و خطای استاندارد آن‌ها به ژورنال متصل است. این رفتار را می‌توان از طریق تنظیمات StandardOutput=/StandardError= در فایل واحد تغییر داد؛ برای جزئیات به systemd.exec(5) مراجعه کنید. ژورنال جریان بایت‌های لاگ دریافت‌شده از این طریق را با تقسیم جریان در خطوط جدید ("\n"، اسکی 10) و بایت‌های NUL، به رکوردهای لاگ مجزا تبدیل می‌کند.

اگر systemd-journald.service متوقف شود، اتصالات جریانی مرتبط با تمامی سرویس‌ها قطع می‌شوند. تلاش‌های بعدی سرویس برای نوشتن در آن جریان‌ها منجر به خطاهای EPIPE خواهد شد. به منظور واکنش مناسب در این حالت، توصیه می‌شود برنامه‌هایی که در خروجی/خطای استاندارد لاگ می‌نویسند چنین خطاهایی را نادیده بگیرند. اگر گرداننده سیگنال یونیکس SIGPIPE مسدود یا غیرفعال نشده باشد، چنین تلاش‌هایی برای نوشتن همچنین منجر به تولید این سیگنال‌های فرایند خواهد شد؛ signal(7) را ببینید. برای کاهش اثرات این مسئله، مدیر سرویس systemd به‌طور صریح و پیش‌فرض سیگنال SIGPIPE را برای تمامی فرایندهای فراخوانی‌شده غیرفعال می‌کند (این مورد را می‌توان برای هر واحد به‌طور جداگانه از طریق گزینه IgnoreSIGPIPE= تغییر داد؛ برای جزئیات به systemd.exec(5) مراجعه کنید). پس از قطع جریان‌های خروجی استاندارد/خطای استاندارد، امکان بازیابی آن‌ها وجود ندارد مگر اینکه سرویس‌های مرتبط با آن‌ها دوباره راه‌اندازی شوند. توجه داشته باشید که در طول عملکرد عادی، systemd-journald.service کپی‌هایی از توصیف‌کننده‌های فایل (file descriptors) این جریان‌ها را در مدیر سرویس نگهداری می‌کند. اگر systemd-journald.service با استفاده از systemctl restart یا عملیات معادل آن به جای یک جفت دستور مجزای systemctl stop و systemctl start (یا عملیات معادل) راه‌اندازی مجدد شود، این اتصالات جریانی قطع نشده و در طول راه‌اندازی مجدد حفظ می‌شوند. بنابراین راه‌اندازی مجدد systemd-journald.service ایمن است، اما متوقف کردن آن توصیه نمی‌شود.

توجه داشته باشید که فرادادهٔ رکورد لاگ برای رکوردهای منتقل‌شده از طریق چنین جریان‌های خروجی/خطای استاندارد، فرادادهٔ همتایی (peer) را بازتاب می‌دهد که جریان در ابتدا برای آن ایجاد شده بود. اگر اتصال جریان به فرایندهای دیگر منتقل شود (مانند فرایندهای فرزند بیشتری که از فرایند اصلی سرویس منشعب شده‌اند)، رکوردهای لاگ فرادادهٔ آن‌ها را بازتاب نخواهند داد، بلکه همچنان به توصیف فرایند اولیه ادامه می‌دهند. این موضوع با سایر روش‌های انتقال لاگ فهرست‌شده در بالا متفاوت است، چرا که آن‌ها ذاتاً مبتنی بر رکورد هستند و فراداده در آن‌ها همواره با تک‌تک رکوردها مرتبط است.

علاوه بر ثبت لاگ ضمنی خروجی/خطای استاندارد سرویس‌ها، ثبت لاگ جریانی از طریق ابزار خط فرمان systemd-cat(1) نیز در دسترس است.

در حال حاضر، تعداد جریان‌های لاگ موازی که systemd-journald می‌پذیرد به ۴۰۹۶ محدود است. هنگامی که این حد تکمیل شود، جریان‌های لاگ بیشتری ممکن است برقرار شوند اما از همان ابتدا خطای EPIPE دریافت خواهند کرد.

«فضاهای نام» ژورنال هم سازوکاری برای جداسازی منطقی جریان لاگ پروژه‌های شامل یک یا چند سرویس از بقیه سیستم هستند و هم سازوکاری برای بهبود کارایی. چندین فضای نام ژورنال می‌توانند به‌طور هم‌زمان وجود داشته باشند که هر کدام جریان لاگ مستقل خود را تعریف می‌کنند و توسط نمونهٔ اختصاصی خود از systemd-journald مدیریت می‌شوند. فضاهای نام هم در مخزن داده و هم در رابط IPC از یکدیگر مستقل هستند. به‌طور پیش‌فرض، تنها یک فضای نام پیش‌فرض وجود دارد که توسط systemd-journald.service (و واحدهای سوکت مرتبط با آن) مدیریت می‌شود. فضاهای نام اضافی با راه‌اندازی نمونه‌ای از الگوی سرویس systemd-journald@.service ایجاد می‌شوند. نام نمونه همان شناسه فضای نام است که رشته‌ای کوتاه بوده و برای اشاره به فضای نام ژورنال استفاده می‌شود. واحدهای سرویس را می‌توان از طریق تنظیم LogNamespace= در فایل واحد به یک فضای نام ژورنال خاص اختصاص داد؛ برای جزئیات به systemd.exec(5) مراجعه کنید. سوئیچ --namespace= در journalctl(1) می‌تواند برای مشاهده جریان لاگ یک فضای نام خاص استفاده شود. اگر از این سوئیچ استفاده نشود، جریان لاگ فضای نام پیش‌فرض نمایش داده می‌شود، یعنی داده‌های لاگ سایر فضاهای نام قابل مشاهده نخواهند بود.

سرویس‌های مرتبط با یک فضای نام لاگ خاص می‌توانند از طریق syslog(3)، پروتکل بومی ثبت لاگ ژورنال و خروجی/خطای استاندارد لاگ ثبت کنند؛ ثبت لاگ از هر سه روش انتقال به آن فضای نام مرتبط خواهد بود.

به‌طور پیش‌فرض، تنها فضای نام پیش‌فرض پیام‌های لاگ هسته و حسابرسی را جمع‌آوری خواهد کرد.

نمونهٔ systemd-journald مربوط به فضای نام پیش‌فرض از طریق /etc/systemd/journald.conf (پایین را ببینید) پیکربندی می‌شود، در حالی که سایر نمونه‌ها از طریق /etc/systemd/journald@NAMESPACE.conf پیکربندی می‌گردند. داده‌های لاگ ژورنال برای فضای نام پیش‌فرض در /var/log/journal/MACHINE_ID (پایین را ببینید) قرار می‌گیرند در حالی که داده‌های سایر فضاهای نام در /var/log/journal/MACHINE_ID.NAMESPACE واقع شده‌اند.

SIGUSR1

درخواست تخلیه (flush) داده‌های ژورنال از /run/ به /var/ به منظور پایدارسازی آن‌ها (در صورت فعال بودن این امکان). این سیگنال باید پس از سوار شدن (mount) /var/ استفاده شود، زیرا در غیر این صورت صرف‌نظر از پیکربندی، داده‌های لاگ از /run/ هرگز به /var/ منتقل نمی‌شوند. از دستور journalctl --flush برای درخواست تخلیه فایل‌های ژورنال و انتظار برای تکمیل عملیات استفاده کنید. برای جزئیات به journalctl(1) مراجعه کنید.

اضافه‌شده در نسخهٔ 186.

SIGUSR2

درخواست چرخش فوری فایل‌های ژورنال. از دستور journalctl --rotate برای درخواست چرخش فایل‌های ژورنال و انتظار برای تکمیل عملیات استفاده کنید.

اضافه‌شده در نسخهٔ 186.

SIGRTMIN+1

درخواست نوشتن تمامی داده‌های لاگ نوشته‌نشده روی دیسک. از دستور journalctl --sync برای فعال‌سازی همگام‌سازی ژورنال و انتظار برای تکمیل عملیات استفاده کنید.

اضافه‌شده در نسخهٔ 228.

SIGHUP

به محض دریافت سیگنال فرایند SIGHUP، systemd-journald مقادیر پیکربندی خود را دوباره بارگذاری کرده و بافر لاگ هسته و ژورنال‌ها را برای بازتاب پیکربندی جدید به‌روزرسانی می‌کند. اگر ReadKmsg= تغییر کرده باشد، بافر لاگ هسته به عنوان بخشی از بارگذاری مجدد تخلیه و به‌روزرسانی خواهد شد. ژورنال فعال (مانند پایدار یا فرّار) همچنان با پیکربندی به‌روزرسانی‌شده مورد استفاده قرار خواهد گرفت. با این حال، اگر حالت ذخیره‌سازی از پایدار به فرّار تغییر کرده باشد و ژورنال فعلی در حال استفاده ژورنال پایدار باشد، آنگاه ژورنال فعال به ژورنال فرّار تغییر خواهد یافت.

اضافه‌شده در نسخهٔ 258.

systemd-journald از منطق اعتبارنامه‌های سرویس همان‌گونه که توسط ImportCredential=/LoadCredential=/SetCredential= پیاده‌سازی شده است پشتیبانی می‌کند (برای جزئیات به systemd.exec(5) مراجعه کنید). اعتبارنامه‌های زیر در صورت ارائه استفاده می‌شوند:

journal.forward_to_socket

می‌تواند حاوی نشانی سوکتی باشد که لاگ‌ها باید به آن بازارسال شوند. ForwardToSocket= در journald.conf(5) را ببینید.

اضافه‌شده در نسخهٔ 256.

journal.storage

می‌تواند برای مشخص کردن محل ذخیره‌سازی فایل‌های ژورنال استفاده شود. Storage= در journald.conf(5) را ببینید.

اضافه‌شده در نسخهٔ 256.

چند پارامتر پیکربندی از journald.conf را می‌توان در خط فرمان هسته بازنویسی کرد:

systemd.journald.forward_to_syslog=, systemd.journald.forward_to_kmsg=, systemd.journald.forward_to_console=, systemd.journald.forward_to_wall=

بازارسال پیام‌های لاگ جمع‌آوری‌شده به syslog، بافر لاگ هسته، کنسول سیستم یا wall را فعال/غیرفعال می‌کند.

برای اطلاعات درباره این تنظیمات به journald.conf(5) مراجعه کنید.

اضافه‌شده در نسخهٔ 186.

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=

حداکثر سطح لاگ پیام‌هایی را که در ژورنال ذخیره می‌شوند یا به syslog(3)، kmsg، کنسول، wall(1) یا یک سوکت بازارسال می‌گردند کنترل می‌کند. این گزینه‌های خط فرمان هسته تنظیمات هم‌نام در فایل journald.conf(5) را بازنویسی می‌کنند.

اضافه‌شده در نسخهٔ 232.

توجه داشته باشید که این گزینه‌های خط فرمان هسته تنها توسط فضای نام پیش‌فرض اعمال می‌شوند؛ بخش بالا را ببینید.

فایل‌های ژورنال به‌طور پیش‌فرض تحت مالکیت گروه سیستمی "systemd-journal" بوده و توسط آن قابل خواندن هستند، اما قابل نوشتن نیستند. بنابراین، افزودن یک کاربر به این گروه او را قادر می‌سازد تا فایل‌های ژورنال را بخواند.

به‌طور پیش‌فرض، هر کاربری که شناسه UID آن خارج از محدودهٔ کاربران سیستم، کاربران پویای سرویس‌ها و کاربر nobody باشد، مجموعه فایل‌های ژورنال مختص به خود را در /var/log/journal/ دریافت خواهد کرد. برای جزئیات بیشتر درباره محدوده‌های UID به Users, Groups, UIDs and GIDs on systemd systems[2] مراجعه کنید. با این حال، به منظور جلوگیری از اینکه کاربر بتواند مستقیماً در این فایل‌های ژورنال بنویسد، این فایل‌ها تحت مالکیت کاربر نخواهند بود. در عوض، از فهرست‌های کنترل دسترسی فایل‌سیستم (ACL) استفاده می‌شود تا اطمینان حاصل شود که کاربر تنها دسترسی خواندن دریافت می‌کند.

به کاربران و گروه‌های دیگر نیز می‌توان از طریق فهرست‌های کنترل دسترسی فایل‌سیستم (ACL) اجازه دسترسی به فایل‌های ژورنال را اعطا کرد. توزیع‌ها و مدیران سیستم ممکن است دسترسی خواندن را به تمام اعضای گروه‌های سیستمی "wheel" و "adm" با دستوری مانند دستور زیر اعطا کنند:

# setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/

توجه داشته باشید که این دستور، ACLها را هم برای فایل‌های ژورنال موجود و هم برای فایل‌های ژورنال آینده که در دایرکتوری /var/log/journal/ ایجاد می‌شوند به‌روزرسانی خواهد کرد.

/etc/systemd/journald.conf

پیکربندی رفتار systemd-journald. به journald.conf(5) مراجعه کنید.

اضافه‌شده در نسخهٔ 206.

/run/log/journal/machine-id/*.journal, /run/log/journal/machine-id/*.journal~, /var/log/journal/machine-id/*.journal, /var/log/journal/machine-id/*.journal~

systemd-journald ورودی‌ها را در فایل‌هایی در /run/log/journal/machine-id/ یا /var/log/journal/machine-id/ با پسوند ".journal" می‌نویسد. اگر دیمن به‌صورت ناتمام یا غیرعادی متوقف شود یا مشخص شود که فایل‌ها خراب شده‌اند، نام آن‌ها با استفاده از پسوند ".journal~" تغییر یافته و systemd-journald شروع به نوشتن در یک فایل جدید می‌کند. /run/ زمانی استفاده می‌شود که /var/log/journal در دسترس نباشد، یا زمانی که Storage=volatile در فایل پیکربندی journald.conf(5) تنظیم شده باشد.

هنگامی که systemd-journald نوشتن در یک فایل ژورنال را متوقف می‌کند، نام آن به "original-name@suffix.journal" (یا "original-name@suffix.journal~") تغییر داده می‌شود. چنین فایل‌هایی «بایگانی‌شده» هستند و دیگر در آن‌ها نوشته نخواهد شد.

به‌طور کلی، خواندن یا کپی کردن هر فایل ژورنال (فعال یا بایگانی‌شده) ایمن است. journalctl(1) و توابع موجود در کتابخانهٔ sd-journal(3) باید بتوانند تمامی ورودی‌هایی را که به‌طور کامل نوشته شده‌اند بخوانند.

systemd-journald به‌طور خودکار قدیمی‌ترین فایل‌های ژورنال بایگانی‌شده را برای محدود کردن میزان مصرف فضای دیسک حذف خواهد کرد. SystemMaxUse= و تنظیمات مرتبط در journald.conf(5) را ببینید.

اضافه‌شده در نسخهٔ 206.

/dev/kmsg, /dev/log, /run/systemd/journal/dev-log, /run/systemd/journal/socket, /run/systemd/journal/stdout

سوکت‌ها و سایر مسیرهای گره فایلی که systemd-journald به آن‌ها گوش می‌دهد و در فایل‌سیستم قابل مشاهده هستند. علاوه بر این‌ها، systemd-journald می‌تواند بسته به اینکه "systemd-journald-audit.socket" فعال باشد یا خیر، با استفاده از netlink(7) به رویدادهای حسابرسی گوش دهد.

اضافه‌شده در نسخهٔ 228.

در صورت استفاده از فضابندی نام ژورنال، این مسیرها اندکی تغییر می‌کنند تا شامل شناسه فضای نام شوند؛ بخش بالا را ببینید.

systemd(1), journalctl(1), journald.conf(5), systemd.journal-fields(7), sd-journal(3), systemd-coredump(8), setfacl(1), sd_journal_print(3), pydoc systemd.journal

1.
Native Journal Protocol
https://systemd.io/JOURNAL_NATIVE_PROTOCOL
2.
Users, Groups, UIDs and GIDs on systemd systems
https://systemd.io/UIDS-GIDS
systemd 261.2