نام (NAME)

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 - سرویس ژورنال

خلاصه دستور (SYNOPSIS)

توضیحات (DESCRIPTION)

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

دیمن به‌طور ضمنی فیلدهای فرادادهٔ متعددی را برای هر پیام لاگ به شیوه‌ای امن و غیرقابل جعل جمع‌آوری می‌کند. برای اطلاعات بیشتر درباره فراداده‌های جمع‌آوری‌شده به 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) مراجعه کنید.

ثبت لاگ جریانی (STREAM LOGGING)

مدیر سرویس 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 دریافت خواهند کرد.

فضاهای نام ژورنال (JOURNAL NAMESPACES)

«فضاهای نام» ژورنال هم سازوکاری برای جداسازی منطقی جریان لاگ پروژه‌های شامل یک یا چند سرویس از بقیه سیستم هستند و هم سازوکاری برای بهبود کارایی. چندین فضای نام ژورنال می‌توانند به‌طور هم‌زمان وجود داشته باشند که هر کدام جریان لاگ مستقل خود را تعریف می‌کنند و توسط نمونهٔ اختصاصی خود از 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 واقع شده‌اند.

سیگنال‌ها (SIGNALS)

SIGUSR1

SIGUSR2

SIGRTMIN+1

SIGHUP

اعتبارنامه‌ها (CREDENTIALS)

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

journal.forward_to_socket

journal.storage

خط فرمان هسته (KERNEL COMMAND LINE)

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

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

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=

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

کنترل دسترسی (ACCESS CONTROL)

فایل‌های ژورنال به‌طور پیش‌فرض تحت مالکیت گروه سیستمی "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/ ایجاد می‌شوند به‌روزرسانی خواهد کرد.

فایل‌ها (FILES)

/etc/systemd/journald.conf

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

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

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

همچنین ببینید (SEE ALSO)

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

نکات (NOTES)

1.

Native Journal Protocol

2.

Users, Groups, UIDs and GIDs on systemd systems