systemd-analyze time

این دستور مدت‌زمان صرف‌شده در هسته (kernel) قبل از رسیدن به فضای کاربری (userspace)، مدت‌زمان صرف‌شده در initrd قبل از رسیدن به فضای کاربری عادی سیستم، و مدت‌زمانی که فضای کاربری عادی سیستم برای مقداردهی اولیه صرف کرده است را چاپ می‌کند. توجه داشته باشید که این اندازه‌گیری‌ها صرفاً زمان سپری‌شده تا نقطه‌ای را می‌سنجند که همه سرویس‌های سیستم اجرا شده باشند، نه لزوماً تا زمانی که مقداردهی اولیه آن‌ها کاملاً تمام شود یا دیسک بیکار گردد.

مثال ۱. نمایش مدت‌زمان راه‌اندازی (بوت)

# in a container
$ systemd-analyze time
Startup finished in 296ms (userspace)
multi-user.target reached after 275ms in userspace
# on a real machine
$ systemd-analyze time
Startup finished in 2.584s (kernel) + 19.176s (initrd) + 47.847s (userspace) = 1min 9.608s
multi-user.target reached after 47.820s in userspace

systemd-analyze blame

این دستور فهرستی از تمام واحدهای در حال اجرا را که بر اساس مدت‌زمان صرف‌شده برای مقداردهی اولیه مرتب شده‌اند، چاپ می‌کند. از این اطلاعات می‌توان برای بهینه‌سازی زمان‌های راه‌اندازی سیستم استفاده کرد. توجه داشته باشید که خروجی ممکن است گمراه‌کننده باشد، زیرا مقداردهی اولیه یک سرویس ممکن است صرفاً به این دلیل کند باشد که منتظر تکمیل مقداردهی اولیه سرویس دیگری است. همچنین توجه کنید: systemd-analyze blame نتایج را برای سرویس‌های دارای Type=simple نمایش نمی‌دهد، زیرا systemd این سرویس‌ها را بلافاصله شروع‌شده در نظر می‌گیرد و بنابراین سنجش تأخیرهای مقداردهی اولیه امکان‌پذیر نیست. همچنین دقت کنید که این دستور فقط زمانی را نشان می‌دهد که واحدها برای راه‌اندازی صرف کرده‌اند، و مدت‌زمانی را که وظایف (jobs) واحد در صف اجرا سپری کرده‌اند نشان نمی‌دهد. به‌ویژه زمانی را نشان می‌دهد که واحدها در وضعیت "activating" سپری کرده‌اند، وضعیتی که برای واحدهایی مانند واحدهای دستگاه (device units) که مستقیماً از "inactive" به "active" تغییر وضعیت می‌دهند تعریف نشده است. از این رو، این دستور تصویری از عملکرد کد برنامه ارائه می‌دهد، اما نمی‌تواند تأخیر ناشی از انتظار برای سخت‌افزار و رویدادهای مشابه را به‌دقت منعکس کند.

مثال ۲. نمایش واحدهایی که بیشترین زمان را در طول بوت صرف کرده‌اند

$ systemd-analyze blame
         32.875s pmlogger.service
         20.905s systemd-networkd-wait-online.service
         13.299s dev-vda1.device
         ...
            23ms sysroot.mount
            11ms initrd-udevadm-cleanup-db.service
             3ms sys-kernel-config.mount

systemd-analyze critical-chain [UNIT...]

این دستور درختی از زنجیره زمانی بحرانی واحدها را چاپ می‌کند (برای هر یک از UNITهای مشخص‌شده یا در غیر این صورت برای هدف پیش‌فرض). زمان پس از فعال شدن یا شروع واحد بعد از نویسه "@" چاپ می‌شود. مدت‌زمانی که واحد برای شروع صرف می‌کند بعد از نویسه "+" چاپ می‌شود. توجه داشته باشید که خروجی ممکن است به دلیل وابستگی مقداردهی اولیه سرویس‌ها به فعال‌سازی سوکت و همچنین اجرای موازی واحدها گمراه‌کننده باشد. همچنین، مشابه دستور blame، این دستور نیز تنها زمان سپری‌شده واحدها در وضعیت "activating" را در نظر می‌گیرد، و بنابراین واحدهایی را که هرگز از وضعیت "activating" عبور نکرده‌اند (مانند واحدهای دستگاه که مستقیماً از "inactive" به "active" منتقل می‌شوند) پوشش نمی‌دهد. علاوه بر این، اطلاعاتی درباره وظایف (و به‌ویژه وظایفی که با پایان مهلت زمانی مواجه شده‌اند) ارائه نمی‌دهد.

مثال ۳. دستور systemd-analyze critical-chain

$ systemd-analyze critical-chain
multi-user.target @47.820s
└─pmie.service @35.968s +548ms
  └─pmcd.service @33.715s +2.247s
    └─network-online.target @33.712s
      └─systemd-networkd-wait-online.service @12.804s +20.905s
        └─systemd-networkd.service @11.109s +1.690s
          └─systemd-udevd.service @9.201s +1.904s
            └─systemd-tmpfiles-setup-dev.service @7.306s +1.776s
              └─kmod-static-nodes.service @6.976s +177ms
                └─systemd-journald.socket
                  └─system.slice
                    └─-.slice

systemd-analyze dump [pattern...]

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

مثال ۴. نمایش وضعیت داخلی مدیر کاربر

$ systemd-analyze --user dump
Timestamp userspace: Thu 2019-03-14 23:28:07 CET
Timestamp finish: Thu 2019-03-14 23:28:07 CET
Timestamp generators-start: Thu 2019-03-14 23:28:07 CET
Timestamp generators-finish: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-start: Thu 2019-03-14 23:28:07 CET
Timestamp units-load-finish: Thu 2019-03-14 23:28:07 CET
-> Unit proc-timer_list.mount:
        Description: /proc/timer_list
        ...
-> Unit default.target:
        Description: Main user target
...

systemd-analyze malloc [D-Bus service...]

از این دستور می‌توان برای درخواست خروجی وضعیت حافظه داخلی (همان‌طور که توسط malloc_info(3) برگردانده می‌شود) یک سرویس D-Bus استفاده کرد. اگر سرویسی مشخص نشود، پرس‌وجو به org.freedesktop.systemd1 (مدیر سرویس سیستم یا کاربر) ارسال خواهد شد. پایداری قالب خروجی تضمین نمی‌شود و نباید توسط برنامه‌ها تجزیه شود.

سرویس باید رابط org.freedesktop.MemoryAllocation1 را پیاده‌سازی کرده باشد. در مجموعه systemd، در حال حاضر این رابط تنها توسط مدیر پیاده‌سازی شده است.

systemd-analyze plot

این دستور یا یک گرافیک SVG چاپ می‌کند که جزئیات سرویس‌های سیستم را با زمان شروع آن‌ها و برجسته‌سازی زمان صرف‌شده برای مقداردهی اولیه نشان می‌دهد، یا داده‌های خام زمانی را در قالب JSON یا جدول نمایش می‌دهد.

مثال ۵. رسم نمودار زمان‌بندی راه‌اندازی (bootchart)

$ systemd-analyze plot >bootup.svg
$ eog bootup.svg&

توجه داشته باشید که این نمودار بر اساس تازه‌ترین داده‌های زمان‌بندی به ازای هر واحد از واحدهای بارگذاری‌شده است. این بدان معناست که اگر واحدی شروع شود، سپس متوقف گردد و دوباره شروع شود، اطلاعات نمایش‌داده‌شده تازه‌ترین چرخه شروع را پوشش می‌دهد، نه اولین چرخه را. بنابراین توصیه می‌شود این اطلاعات تنها کمی پس از بوت بررسی شود تا این تمایز تأثیری نداشته باشد. علاوه بر این، واحدهایی که توسط هیچ واحد دیگری از طریق یک وابستگی ارجاع داده نشده‌اند، ممکن است پس از خاتمه (در صورتی که با شکست مواجه نشده باشند) توسط مدیر سرویس از حافظه تخلیه شوند. چنین واحدهایی در نمودار نشان داده نخواهند شد.

systemd-analyze dot [pattern...]

این دستور توصیف متنی گراف وابستگی را در قالب dot برای پردازش بیشتر با ابزار GraphViz dot(1) تولید می‌کند. برای ایجاد یک درخت گرافیکی از وابستگی‌ها از خط فرمانی مانند systemd-analyze dot | dot -Tsvg >systemd.svg استفاده کنید. مگر اینکه --order یا --require ارسال شود، گراف تولیدشده هم وابستگی‌های ترتیبی و هم وابستگی‌های نیازمندی را نشان می‌دهد. مشخصات اختیاری با سبک الگوی تطبیق (مانند *.target) می‌تواند در انتها داده شود. اگر هر یک از این الگوها با گره مبدأ یا مقصد مطابقت داشته باشد، وابستگی واحد در گراف گنجانده می‌شود.

مثال ۶. رسم تمام وابستگی‌های هر واحدی که نام آن با "avahi-daemon" شروع می‌شود

$ systemd-analyze dot 'avahi-daemon.*' | dot -Tsvg >avahi.svg
$ eog avahi.svg

مثال ۷. رسم وابستگی‌های میان تمام واحدهای هدف شناخته‌شده

$ systemd-analyze dot --to-pattern='*.target' --from-pattern='*.target' \
      | dot -Tsvg >targets.svg
$ eog targets.svg

systemd-analyze unit-paths

این دستور فهرستی از تمام دایرکتوری‌هایی را چاپ می‌کند که فایل‌های واحد، بازنویسی‌های .d و پیوندهای نمادین .wants و .requires ممکن است از آن‌ها بارگذاری شوند. این دستور را با --user ترکیب کنید تا فهرست مربوط به نمونه مدیر کاربر، و با --global برای دریافت پیکربندی سراسری نمونه‌های مدیر کاربر بازیابی شود.

مثال ۸. نمایش تمام مسیرها برای واحدهای تولیدشده

$ systemd-analyze unit-paths | grep '^/run'
/run/systemd/system.control
/run/systemd/transient
/run/systemd/generator.early
/run/systemd/system
/run/systemd/system.attached
/run/systemd/generator
/run/systemd/generator.late

توجه داشته باشید که این دستور فهرستی را چاپ می‌کند که درون خود systemd-analyze کامپایل شده است و با مدیر در حال اجرا ارتباط برقرار نمی‌کند. برای دریافت فهرست واقعی که مدیر استفاده می‌کند (با حذف دایرکتوری‌های خالی) از دستور زیر استفاده کنید:

systemctl [--user] [--global] show -p UnitPath --value

systemd-analyze exit-status [STATUS...]

این دستور فهرستی از وضعیت‌های خروج را به همراه «کلاس» آن‌ها، یعنی منبع تعریف (یکی از "libc"، "systemd"، "LSB"، یا "BSD") چاپ می‌کند؛ بخش کدهای خروج فرایند در systemd.exec(5) را ببینید. اگر هیچ آرگومان اضافی مشخص نشود، تمام وضعیت‌های شناخته‌شده نشان داده می‌شوند. در غیر این صورت، تنها تعاریف کدهای مشخص‌شده نمایش داده خواهند شد.

مثال ۹. نمایش چند نمونه از نام‌های وضعیت خروج

$ systemd-analyze exit-status 0 1 {63..65}
NAME    STATUS CLASS
SUCCESS 0      libc
FAILURE 1      libc
-       63     -
USAGE   64     BSD
DATAERR 65     BSD

systemd-analyze capability [CAPABILITY... | {-m | --mask} MASK]

این دستور فهرستی از قابلیت‌های لینوکس را به همراه شناسه‌های عددی آن‌ها چاپ می‌کند. برای جزئیات به capabilities(7) مراجعه فرمایید. اگر هیچ آرگومانی مشخص نشود، فهرست کامل قابلیت‌های شناخته‌شده برای مدیر سرویس و هسته نشان داده می‌شود. قابلیت‌هایی که توسط هسته تعریف شده‌اند اما برای مدیر سرویس شناخته‌شده نیستند به‌صورت "cap_???" نمایش داده می‌شوند. در صورت تمایل، اگر آرگومان‌هایی مشخص شوند می‌توانند به قابلیت‌های خاصی بر اساس نام یا شناسه عددی اشاره کنند، که در این حالت تنها قابلیت‌های مشخص‌شده در جدول نمایش داده می‌شوند.

همچنین اگر --mask ارسال شود، باید یک آرگومان عددی واحد مشخص شود که به عنوان یک ماسک قابلیت هگزادسیمال تفسیر می‌شود. در این حالت، تنها قابلیت‌های موجود در ماسک در جدول نشان داده خواهند شد. این حالت برای کمک به رمزگشایی مجموعه‌های قابلیت موجود از طریق رابط‌های عیب‌یابی گوناگون (مانند "/proc/PID/status") طراحی شده است.

مثال ۱۰. نمایش چند نمونه از نام‌های قابلیت‌ها

$ systemd-analyze capability 0 1 {30..32}
NAME              NUMBER
cap_chown              0
cap_dac_override       1
cap_audit_control     30
cap_setfcap           31
cap_mac_override      32

مثال ۱۱. رمزگشایی یک ماسک قابلیت استخراج‌شده از proc/

$ systemd-analyze capability -m 0000000000003c00
NAME                 NUMBER
cap_net_bind_service     10
cap_net_broadcast        11
cap_net_admin            12
cap_net_raw              13

systemd-analyze condition CONDITION...

این دستور انتساب‌های Condition*=... و Assert*=... را ارزیابی کرده و مقادیر آن‌ها و مقدار نهایی حاصل از مجموعه شرایط ترکیبی را چاپ می‌کند. برای فهرستی از شرایط و ادعاهای موجود به systemd.unit(5) مراجعه کنید.

مثال ۱۲. ارزیابی شرایطی که نسخه‌های هسته را بررسی می‌کنند

$ systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
        'ConditionKernelVersion = >=5.1' \
        'ConditionACPower=|false' \
        'ConditionArchitecture=|!arm' \
        'AssertPathExists=/etc/os-release'
test.service: AssertPathExists=/etc/os-release succeeded.
Asserts succeeded.
test.service: ConditionArchitecture=|!arm succeeded.
test.service: ConditionACPower=|false failed.
test.service: ConditionKernelVersion=>=5.1 succeeded.
test.service: ConditionKernelVersion=!<4.0 succeeded.
Conditions succeeded.

systemd-analyze syscall-filter [SET...]

این دستور فراخوانی‌های سیستمی موجود در مجموعه سیستم‌کال مشخص‌شده SET، یا در صورت عدم تعیین، تمام مجموعه‌های شناخته‌شده را فهرست می‌کند. آرگومان SET باید شامل پیشوند "@" باشد.

systemd-analyze filesystems [SET...]

این دستور سیستم‌های فایل موجود در مجموعه سیستم فایل مشخص‌شده SET، یا در صورت عدم تعیین، تمام مجموعه‌های شناخته‌شده را فهرست می‌کند. آرگومان SET باید شامل پیشوند "@" باشد.

systemd-analyze calendar EXPRESSION...

این دستور رویدادهای زمانی تکرارشونده تقویم را تجزیه و استانداردسازی (نرمال‌سازی) کرده و زمان سررسید بعدی آن‌ها را محاسبه می‌کند. این دستور همان ورودی تنظیم OnCalendar= در systemd.timer(5) را بر اساس نحو توصیف‌شده در systemd.time(7) دریافت می‌کند. به‌طور پیش‌فرض، تنها سررسید بعدی عبارت تقویمی نشان داده می‌شود؛ از --iterations= برای نمایش تعداد دفعات سررسید مشخص‌شده بعدی عبارت استفاده کنید. هر بار سررسید عبارت یک برچسب زمانی تشکیل می‌دهد، دستور فرعی timestamp را در زیر ببینید.

مثال ۱۳. نمایش روزهای کبیسه در آینده نزدیک

$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'
  Original form: *-2-29 0:0:0
Normalized form: *-02-29 00:00:00
    Next elapse: Sat 2020-02-29 00:00:00 UTC
       From now: 11 months 15 days left
       Iter. #2: Thu 2024-02-29 00:00:00 UTC
       From now: 4 years 11 months left
       Iter. #3: Tue 2028-02-29 00:00:00 UTC
       From now: 8 years 11 months left
       Iter. #4: Sun 2032-02-29 00:00:00 UTC
       From now: 12 years 11 months left
       Iter. #5: Fri 2036-02-29 00:00:00 UTC
       From now: 16 years 11 months left

systemd-analyze timestamp TIMESTAMP...

این دستور یک برچسب زمانی (یعنی یک نقطه منفرد در زمان) را تجزیه کرده و شکل استانداردشده و اختلاف میان این برچسب زمانی و زمان حال را خروجی می‌دهد. برچسب زمانی باید با نحو مستندشده در systemd.time(7)، بخش "PARSING TIMESTAMPS" مطابقت داشته باشد.

مثال ۱۴. نمایش تجزیه برچسب‌های زمانی

$ systemd-analyze timestamp yesterday now tomorrow
  Original form: yesterday
Normalized form: Mon 2019-05-20 00:00:00 CEST
       (in UTC): Sun 2019-05-19 22:00:00 UTC
   UNIX seconds: @15583032000
       From now: 1 day 9h ago
  Original form: now
Normalized form: Tue 2019-05-21 09:48:39 CEST
       (in UTC): Tue 2019-05-21 07:48:39 UTC
   UNIX seconds: @1558424919.659757
       From now: 43us ago
  Original form: tomorrow
Normalized form: Wed 2019-05-22 00:00:00 CEST
       (in UTC): Tue 2019-05-21 22:00:00 UTC
   UNIX seconds: @15584760000
       From now: 14h left

systemd-analyze timespan EXPRESSION...

این دستور یک بازه زمانی (یعنی اختلاف بین دو برچسب زمانی) را تجزیه کرده و شکل استانداردشده و مقدار معادل آن را برحسب میکروثانیه خروجی می‌دهد. بازه زمانی باید از نحو مستندشده در systemd.time(7)، بخش "PARSING TIME SPANS" پیروی کند. مقادیر بدون واحد به عنوان ثانیه در نظر گرفته می‌شوند.

مثال ۱۵. نمایش تجزیه بازه‌های زمانی

$ systemd-analyze timespan 1s 300s '1year 0.000001s'
Original: 1s
      μs: 1000000
   Human: 1s
Original: 300s
      μs: 300000000
   Human: 5min
Original: 1year 0.000001s
      μs: 31557600000001
   Human: 1y 1us

systemd-analyze cat-config NAME|PATH...

این دستور مشابه systemctl cat است، اما روی فایل‌های پیکربندی عمل می‌کند. این دستور محتوای یک فایل پیکربندی و هرگونه فایل drop-in را با استفاده از مجموعه دایرکتوری‌ها و قوانین اولویت معمول systemd به خروجی استاندارد کپی می‌کند. هر آرگومان باید یک مسیر مطلق شامل پیشوند (مانند /etc/systemd/logind.conf یا /usr/lib/systemd/logind.conf) یا یک نام نسبی نسبت به پیشوند (مانند systemd/logind.conf) باشد.

مثال ۱۶. نمایش پیکربندی logind

$ systemd-analyze cat-config systemd/logind.conf
# /etc/systemd/logind.conf
...
[Login]
NAutoVTs=8
...
# /usr/lib/systemd/logind.conf.d/20-test.conf
... some override from another package
# /etc/systemd/logind.conf.d/50-override.conf
... some administrator override

systemd-analyze compare-versions VERSION1 [OP] VERSION2

این دستور بسته به اینکه عملگر OP مشخص شده باشد یا خیر، دو حالت عملکرد متمایز دارد.

در حالت اول — زمانی که OP مشخص نشده است — دو رشته نسخه را با یکدیگر مقایسه کرده و بسته به مورد، یکی از عبارت‌های "VERSION1 < VERSION2"، یا "VERSION1 == VERSION2"، یا "VERSION1 > VERSION2" را چاپ می‌کند.

وضعیت خروج در صورتی که نسخه‌ها برابر باشند برابر 0، اگر نسخه سمت راست کوچک‌تر باشد برابر 11، و اگر نسخه سمت چپ کوچک‌تر باشد برابر 12 خواهد بود. (این منطبق بر قراردادی است که توسط rpmdev-vercmp استفاده می‌شود.)

در حالت دوم — زمانی که OP مشخص شده است — دو رشته نسخه را با استفاده از عملگر OP مقایسه کرده و در صورت برآورده شدن شرط، مقدار 0 (موفقیت) و در غیر این صورت مقدار 1 (شکست) را بازمی‌گرداند. OP می‌تواند یکی از مقادیر lt، le، eq، ne، ge، gt باشد. در این حالت، هیچ خروجی چاپ نمی‌شود. (این رفتار منطبق بر قراردادی است که توسط گزینه --compare-versions در dpkg(1) استفاده می‌شود.)

مثال ۱۷. مقایسه نسخه‌های یک بسته

$ systemd-analyze compare-versions systemd-250~rc1.fc36.aarch64 systemd-251.fc36.aarch64
systemd-250~rc1.fc36.aarch64 < systemd-251.fc36.aarch64
$ echo $?
12
$ systemd-analyze compare-versions 1 lt 2; echo $?
0
$ systemd-analyze compare-versions 1 ge 2; echo $?
1

systemd-analyze verify FILE...

این دستور فایل‌های واحد را بارگذاری کرده و در صورت شناسایی هرگونه خطا، هشدارهایی را چاپ می‌کند. علاوه بر فایل‌های مشخص‌شده در خط فرمان، سایر واحدهای ارجاع‌شده توسط آن‌ها نیز بارگذاری خواهند شد. نام یک واحد روی دیسک را می‌توان با مشخص کردن یک نام مستعار پس از دونقطه بازنویسی کرد؛ برای نمونه مثال زیر را ببینید. مسیر کامل جستجوی واحد با ترکیب دایرکتوری‌های تمام آرگومان‌های خط فرمان و مسیرهای معمول بارگذاری واحد تشکیل می‌شود. متغیر $SYSTEMD_UNIT_PATH پشتیبانی می‌شود و می‌توان از آن برای جایگزینی یا افزودن به مجموعه مسیرهای کامپایل‌شده بارگذاری واحد استفاده کرد؛ به systemd.unit(5) مراجعه فرمایید. تمام فایل‌های واحدهای موجود در دایرکتوری‌های حاوی آرگومان‌های خط فرمان با اولویت نسبت به سایر مسیرها استفاده خواهند شد. اگر یک واحد قالب بدون نام نمونه (مانند foo@.service) مشخص شود، "test_instance" به عنوان نام نمونه استفاده خواهد شد که می‌توان آن را با گزینه --instance= کنترل نمود.

خطاهای زیر در حال حاضر شناسایی می‌شوند:

مثال ۱۸. دستورالعمل‌های دارای املای نادرست

$ cat ./user.slice
[Unit]
WhatIsThis=11
Documentation=man:nosuchfile(1)
Requires=different.service
[Service]
Description=x
$ systemd-analyze verify ./user.slice
[./user.slice:9] Unknown lvalue 'WhatIsThis' in section 'Unit'
[./user.slice:13] Unknown section 'Service'. Ignoring.
Error: org.freedesktop.systemd1.LoadFailed:
   Unit different.service failed to load:
   No such file or directory.
Failed to create user.slice/start: Invalid argument
user.slice: man nosuchfile(1) command failed with code 16

مثال ۱۹. واحدهای سرویس مفقود

$ tail ./a.socket ./b.socket
==> ./a.socket <==
[Socket]
ListenStream=100
==> ./b.socket <==
[Socket]
ListenStream=100
Accept=yes
$ systemd-analyze verify ./a.socket ./b.socket
Service a.service not loaded, a.socket cannot be started.
Service b@0.service not loaded, b.socket cannot be started.

مثال ۲۰. تعیین نام مستعار برای یک واحد

$ cat /tmp/source
[Unit]
Description=Hostname printer
[Service]
Type=simple
ExecStart=/usr/bin/echo %H
MysteryKey=true
$ systemd-analyze verify /tmp/source
Failed to prepare filename /tmp/source: Invalid argument
$ systemd-analyze verify /tmp/source:alias.service
alias.service:7: Unknown key name 'MysteryKey' in section 'Service', ignoring.

systemd-analyze security [UNIT...]

این دستور تنظیمات امنیتی و ایزوله‌سازی (sandboxing) یک یا چند واحد سرویس مشخص‌شده را تحلیل می‌کند. اگر دست‌کم یک نام واحد مشخص شود، تنظیمات امنیتی واحدهای سرویس مشخص بازرسی شده و تحلیلی با جزئیات کامل نمایش داده می‌شود. اگر هیچ نام واحدی مشخص نشود، تمام واحدهای سرویس طولانی‌مدت که در حال حاضر بارگذاری شده‌اند بازرسی شده و جدولی خلاصه همراه با نتایج نمایش داده می‌شود. این دستور تنظیمات مختلف سرویس را که با امنیت مرتبط هستند بررسی کرده و بسته به اهمیت هر تنظیم، یک مقدار عددی به عنوان «سطح مواجهه» (exposure level) به آن اختصاص می‌دهد. سپس یک سطح مواجهه کلی برای کل واحد محاسبه می‌کند که تخمینی در بازه ۰.۰ تا ۱۰.۰ است و نشان می‌دهد یک سرویس از منظر امنیتی چقدر در معرض آسیب‌پذیری قرار دارد. سطوح مواجهه بالا نشان‌دهنده ایزوله‌سازی بسیار اندک است. سطوح مواجهه پایین نشان‌دهنده ایزوله‌سازی سخت‌گیرانه و بالاترین محدودیت‌های امنیتی است. توجه داشته باشید که این دستور تنها قابلیت‌های امنیتی مربوط به هر سرویس را که خود systemd پیاده‌سازی می‌کند تحلیل می‌نماید. این بدان معناست که هیچ سازوکار امنیتی اضافی اعمال‌شده توسط خود کد سرویس لحاظ نمی‌شود. سطح مواجهه تعیین‌شده نباید نادرست برداشت شود: سطح مواجهه بالا نه به این معناست که هیچ ایزوله‌سازی مؤثری توسط خود کد سرویس اعمال نشده است، و نه به این معناست که سرویس لزوماً در برابر حملات محلی یا از راه دور آسیب‌پذیر است. با این وجود، سطوح مواجهه بالا نشان می‌دهند که به احتمال زیاد سرویس می‌تواند از تنظیمات امنیتی تکمیلی بهره‌مند شود.

لطفاً توجه داشته باشید که بسیاری از تنظیمات امنیتی و ایزوله‌سازی به‌تنهایی قابل دور زدن هستند — مگر اینکه با موارد دیگر ترکیب شوند. به عنوان مثال، اگر یک سرویس امتیاز ایجاد یا لغو نقاط اتصال (mount points) را حفظ کند، بسیاری از گزینه‌های ایزوله‌سازی می‌توانند توسط خود کد سرویس خنثی شوند. به همین دلیل بسیار حائز اهمیت است که هر سرویس از جامع‌ترین و سخت‌گیرانه‌ترین تنظیمات ایزوله‌سازی و امنیتی ممکن استفاده کند. این ابزار برخی از این ترکیبات و روابط میان تنظیمات را در نظر می‌گیرد، اما نه همه آن‌ها را. همچنین دقت کنید تنظیمات امنیتی و ایزوله‌سازی که در اینجا تحلیل می‌شوند، تنها بر عملیاتی اعمال می‌گردند که توسط خود کد سرویس اجرا می‌شوند. اگر سرویسی به یک سامانه ارتباط بین‌فرایندی (مانند D-Bus) دسترسی داشته باشد، ممکن است عملیاتی را از سایر سرویس‌ها درخواست کند که مشمول همان محدودیت‌ها نیستند. بنابراین هرگونه تحلیل جامع امنیت و ایزوله‌سازی در صورتی که خط‌مشی دسترسی سامانه ارتباط بین‌فرایندی اعتبارسنجی نشود، ناقص خواهد بود.

مثال ۲۱. تحلیل systemd-logind.service

$ systemd-analyze security --no-pager systemd-logind.service
  NAME                DESCRIPTION                              EXPOSURE
✗ PrivateNetwork=     Service has access to the host's network      0.5
✗ User=/DynamicUser=  Service runs as root user                     0.4
✗ DeviceAllow=        Service has no device ACL                     0.2
✓ IPAddressDeny=      Service blocks all IP address ranges
...
→ Overall exposure level for systemd-logind.service: 4.1 OK 🙂

systemd-analyze inspect-elf FILE...

این دستور فایل‌های مشخص‌شده را بارگذاری می‌کند و اگر آن‌ها اشیاء ELF (فایل‌های اجرایی، کتابخانه‌ها، فایل‌های core و غیره) باشند، فراداده‌های بسته‌بندی تعبیه‌شده را (در صورت وجود) تجزیه کرده و آن را در قالب جدول یا json چاپ می‌کند. برای اطلاعات بیشتر به مستندات فراداده‌های بسته‌بندی (Packaging Metadata)[1] مراجعه فرمایید.

مثال ۲۲. چاپ اطلاعات مربوط به یک فایل core به صورت JSON

$ systemd-analyze inspect-elf core.service.1000.5e02422a5e98450a9d391060932204eb.11478.1683820256000000
{
        "elfType" : "coredump",
        "elfArchitecture" : "AMD x86-64",
        ...
        "packageMetadata" : {
                "systemd" : {
                        "type" : "rpm",
                        "name" : "systemd",
                        "version" : "253",
                        "release" : "8.fc38",
                        "architecture" : "x86_64"
                }
        }
}

systemd-analyze fdstore UNIT...

محتویات فعلی مخزن توصیف‌گر فایل واحد سرویس مشخص‌شده را فهرست می‌کند. این دستور نام‌ها، انواع inode، شماره‌های دستگاه، شماره‌های inode، مسیرها و حالت‌های باز بودن توصیف‌گرهای فایل باز را نشان می‌دهد. برای واحدهای مشخص‌شده باید FileDescriptorStoreMax= فعال باشد؛ برای جزئیات به systemd.service(5) مراجعه کنید.

مثال ۲۳. خروجی جدول

$ systemd-analyze fdstore systemd-journald.service
FDNAME TYPE DEVNO   INODE RDEVNO PATH             FLAGS
stored sock 0:8   4218620 -      socket:[4218620] ro
stored sock 0:8   4213198 -      socket:[4213198] ro
stored sock 0:8   4213190 -      socket:[4213190] ro
...

نکته: ستون "DEVNO" به شماره‌های اصلی/فرعی گره دستگاه پشتیبان سیستم فایلی که inode توصیف‌گر فایل روی آن قرار دارد اشاره دارد. ستون "RDEVNO" به شماره‌های اصلی/فرعی خود گره دستگاه در صورتی که توصیف‌گر فایل به آن ارجاع دهد اشاره می‌کند. با فیلدهای متناظر .st_dev و .st_rdev در struct stat مقایسه فرمایید (برای جزئیات به stat(2) مراجعه کنید). شماره‌های inode فهرست‌شده در ستون "INODE" روی سیستم فایل مشخص‌شده توسط "DEVNO" قرار دارند.

systemd-analyze image-policy POLICY...

این دستور رشته خط‌مشی ایمیج مشخص‌شده را طبق systemd.image-policy(7) تحلیل می‌کند. خط‌مشی استانداردسازی و ساده‌سازی می‌شود. برای هر شناسه پارتیشن تعریف‌شده فعلی (مطابق با مشخصات پارتیشن‌های قابل کشف (Discoverable Partitions Specification)[2]) اثر رشته خط‌مشی ایمیج به صورت جدولی نشان داده می‌شود.

مثال ۲۴. نمونه خروجی

$ systemd-analyze image-policy swap=encrypted:usr=read-only-on+verity:root=encrypted
Analyzing policy: root=encrypted:usr=verity+read-only-on:swap=encrypted
       Long form: root=encrypted:usr=verity+read-only-on:swap=encrypted:=unused+absent
PARTITION       MODE        READ-ONLY GROWFS
root            encrypted   -         -
usr             verity      yes       -
home            ignore      -         -
srv             ignore      -         -
esp             ignore      -         -
xbootldr        ignore      -         -
swap            encrypted   -         -
root-verity     ignore      -         -
usr-verity      unprotected yes       -
root-verity-sig ignore      -         -
usr-verity-sig  ignore      -         -
tmp             ignore      -         -
var             ignore      -         -
default         ignore      -         -

systemd-analyze has-tpm2

گزارش می‌دهد که آیا سیستم به یک دستگاه TPM2 قابل استفاده مجهز است یا خیر. اگر یک دستگاه TPM2 کشف شود، پشتیبانی گردد و توسط سفت‌افزار، درایورهای هسته سیستم‌عامل و فضای کاربری (یعنی systemd) استفاده شود، مقدار "yes" را چاپ کرده و با کد خروج صفر خارج می‌شود. اگر چنین دستگاهی کشف/پشتیبانی/استفاده نشود، "no" را چاپ می‌کند. در غیر این صورت، "partial" را چاپ می‌نماید. در هر یک از این دو حالت اخیر با وضعیت خروج غیرصفر خارج می‌شود. همچنین پنج خط را نمایش می‌دهد که به‌طور جداگانه مشخص می‌کنند آیا سفت‌افزار، درایورها، سیستم، هسته و کتابخانه‌ها TPM2 را شناسایی/پشتیبانی/استفاده کرده‌اند یا خیر. در حال حاضر، کتابخانه‌های مورد نیاز عبارتند از: libtss2-esys.so.0، libtss2-rc.so.0، و libtss2-mu.so.0. این نیازمندی ممکن است در نسخه‌های آینده تغییر کند.

توجه داشته باشید که این دستور تنها دستگاه‌های TPM 2.0 را بررسی می‌کند و TPM 1.2 را اصلاً در نظر نمی‌گیرد.

همراه با --quiet برای جلوگیری از نمایش خروجی استفاده نمایید.

مثال ۲۵. نمونه خروجی

yes
+firmware
+driver
+system
+subsystem
+libraries
  +libtss2-esys.so.0
  +libtss2-rc.so.0
  +libtss2-mu.so.0

اضافه‌شده در نسخه ۲۵۷.

systemd-analyze pcrs [PCR...]

این دستور PCRهای شناخته‌شده TPM2 را به همراه نام‌های شناسایی و مقادیر فعلی آن‌ها نمایش می‌دهد.

مثال ۲۶. نمونه خروجی

$ systemd-analyze pcrs
NR NAME                SHA256
 0 platform-code       bcd2eb527108bbb1f5528409bcbe310aa9b74f687854cc5857605993f3d9eb11
 1 platform-config     b60622856eb7ce52637b80f30a520e6e87c347daa679f3335f4f1a600681bb01
 2 external-code       1471262403e9a62f9c392941300b4807fbdb6f0bfdd50abfab752732087017dd
 3 external-config     3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
 4 boot-loader-code    939f7fa1458e1f7ce968874d908e524fc0debf890383d355e4ce347b7b78a95c
 5 boot-loader-config  864c61c5ea5ecbdb6951e6cb6d9c1f4b4eac79772f7fe13b8bece569d83d3768
 6 -                   3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
 7 secure-boot-policy  9c905bd9b9891bfb889b90a54c4b537b889cfa817c4389cc25754823a9443255
 8 -                   0000000000000000000000000000000000000000000000000000000000000000
 9 kernel-initrd       9caa29b128113ef42aa53d421f03437be57211e5ebafc0fa8b5d4514ee37ff0c
10 ima                 5ea9e3dab53eb6b483b6ec9e3b2c712bea66bca1b155637841216e0094387400
11 kernel-boot         0000000000000000000000000000000000000000000000000000000000000000
12 kernel-config       627ffa4b405e911902fe1f1a8b0164693b31acab04f805f15bccfe2209c7eace
13 sysexts             0000000000000000000000000000000000000000000000000000000000000000
14 shim-policy         0000000000000000000000000000000000000000000000000000000000000000
15 system-identity     0000000000000000000000000000000000000000000000000000000000000000
16 debug               0000000000000000000000000000000000000000000000000000000000000000
17 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22 -                   ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23 application-support 0000000000000000000000000000000000000000000000000000000000000000

systemd-analyze srk [>FILE]

این دستور کلید ریشه ذخیره‌سازی (SRK) را از دستگاه TPM2 خوانده و آن را در قالب بسته‌بندی‌شده TPM2B_PUBLIC به خروجی استاندارد می‌نویسد. خروجی حاوی داده‌های غیرقابل چاپ است، بنابراین باید به یک فایل یا لوله (pipe) هدایت شود.

مثال ۲۷. ذخیره کلید ریشه ذخیره‌سازی در srk.tpm2b_public

systemd-analyze srk >srk.tpm2b_public

systemd-analyze architectures [NAME...]

تمام معماری‌های شناخته‌شده CPU و اینکه کدام موارد بومی (native) هستند را فهرست می‌کند. نام‌های معماری فهرست‌شده مواردی هستند که ConditionArchitecture= از آن‌ها پشتیبانی می‌کند؛ برای جزئیات به systemd.unit(5) مراجعه نمایید. اگر نام‌های معماری مشخص شده باشند، تنها موارد مشخص‌شده فهرست می‌شوند.

مثال ۲۸. خروجی جدول

$ systemd-analyze architectures
NAME        SUPPORT
alpha       foreign
arc         foreign
arc-be      foreign
arm         foreign
arm64       foreign
...
sparc       foreign
sparc64     foreign
tilegx      foreign
x86         secondary
x86-64      native

systemd-analyze smbios11

فهرستی از رشته‌های SMBIOS نوع ۱۱ ارسال‌شده به سیستم را نشان می‌دهد. همچنین به smbios-type-11(7) مراجعه کنید.

مثال ۲۹. نمونه خروجی

$ systemd-analyze smbios11
io.systemd.stub.kernel-cmdline-extra=console=ttyS0
io.systemd.credential.binary:ssh.ephemeral-authorized_keys-all=c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSURGd20xbFp4WlRGclJteG9ZQlozOTYzcE1uYlJCaDMwM1MxVXhLSUM2NmYgbGVubmFydEB6ZXRhCg==
io.systemd.credential:vmm.notify_socket=vsock-stream:2:254570042
3 SMBIOS Type #11 strings passed.

اضافه‌شده در نسخه ۲۵۷.