systemd-analyze time¶

يطبع هذا الأمر الوقت المقضي في النواة قبل الوصول إلى مساحة المستخدم، والوقت المقضي في initrd قبل الوصول إلى مساحة مستخدم النظام العادية، والوقت الذي استغرقته مساحة مستخدم النظام العادية للتهيئة. لاحظ أن هذه القياسات تقيس ببساطة الوقت المنقضي حتى النقطة التي أُنشئت فيها جميع خدمات النظام، ولكن ليس بالضرورة حتى انتهائها تمامًا من التهيئة أو خمول القرص.

مثال 1. عرض الوقت الذي استغرقه الإقلاع

# في حاوية
$ systemd-analyze time
Startup finished in 296ms (userspace)
multi-user.target reached after 275ms in userspace
# على آلة حقيقية
$ 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 يعتبر أن هذه الخدمات بدأت فورًا، وبالتالي لا يمكن إجراء قياس لتأخيرات التهيئة. لاحظ أيضًا أن هذا الأمر يعرض فقط الوقت الذي استغرقته الوحدات لبدء التشغيل، ولا يعرض المدة التي قضتها مهام الوحدات في طابور التنفيذ. وهو يعرض بشكل خاص الوقت الذي قضته الوحدات في حالة "التنشيط" (activating)، وهو أمر غير محدد لوحدات مثل وحدات الأجهزة التي تنتقل مباشرة من "غير نشط" (inactive) إلى "نشط" (active). وبالتالي يعطي هذا الأمر انطباعًا عن أداء كود البرنامج، ولكنه لا يمكنه أن يعكس بدقة الكمون الناتج عن انتظار الأجهزة والأحداث المماثلة.

مثال 2. عرض الوحدات التي استغرقت أطول وقت أثناء الإقلاع

$ 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...]¶

يطبع هذا الأمر شجرة من السلسلة الحرجة زمنياً للوحدات (لكل من الـ UNITs المحددة أو للهدف المبدئي بخلاف ذلك). يُطبع الوقت بعد أن تصبح الوحدة نشطة أو تبدأ بعد المحرف "@". ويُطبع الوقت الذي تستغرقه الوحدة للبدء بعد المحرف "+". لاحظ أن المخرجات قد تكون مضللة لأن تهيئة الخدمات قد تعتمد على تنشيط المقبس وبسبب التنفيذ المتوازي للوحدات. وأيضًا، على غرار أمر blame، يأخذ هذا في الاعتبار فقط الوقت الذي قضته الوحدات في حالة "التنشيط"، وبالتالي لا يغطي الوحدات التي لم تمر أبدًا بحالة "تنشيط" (مثل وحدات الأجهزة التي تنتقل مباشرة من "غير نشط" إلى "نشط"). وعلاوة على ذلك، فإنه لا يعرض معلومات عن المهام (وبالأخص المهام التي انتهت مهلتها).

مثال 3. 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 اختياري، مما يؤدي إلى قصر المخرجات على الوحدات التي تطابق أسماؤها أحد الأنماط. تنسيق المخرجات عرضة للتغيير دون إشعار ويجب ألا يتم تحليله بواسطة التطبيقات. هذا الأمر محدود المعدل للمستخدمين غير المتميزين.

مثال 4. عرض الحالة الداخلية لمديرة المستخدم

$ 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 أو بتنسيق جدول.

مثال 5. رسم مخطط بياني للإقلاع

$ 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) في النهاية. تُضمّن تبعية الوحدة في المخطط إذا تطابق أي من هذه الأنماط مع العقدة المصدر أو العقدة الوجهة.

مثال 6. رسم جميع تبعيات أي وحدة يبدأ اسمها بـ "avahi-daemon"

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

مثال 7. رسم التبعيات بين جميع وحدات الأهداف المعروفة

$ 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 للتكوين العام لنسخ مديرة المستخدم.

مثال 8. عرض جميع المسارات للوحدات المولدة

$ 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). في حال عدم تحديد وسائط إضافية، تُعرض جميع الحالات المعروفة. وإلا، تُعرض فقط التعريفات للأكواد المحددة.

مثال 9. عرض بعض الأمثلة لأسماء حالات الخروج

$ systemd-analyze exit-status 0 1 {63..65}
الاسم    الحالة الفئة
SUCCESS 0      libc
FAILURE 1      libc
-       63     -
USAGE   64     BSD
DATAERR 65     BSD

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

يطبع هذا الأمر قائمة بقدرات لينكس (Linux capabilities) مع معرفاتها الرقمية. انظر capabilities(7) للتفاصيل. في حال عدم تحديد أي وسيط، تُعرض القائمة الكاملة للقدرات المعروفة لمديرة الخدمة والنواة. تُعرض القدرات التي تعرفها النواة ولكن لا تعرفها مديرة الخدمة على هيئة "cap_???". اختيارياً، إذا حُددت وسائط، فقد تشير إلى قدرات محددة بالاسم أو المعرف الرقمي، وفي هذه الحالة تُعرض القدرات المشار إليها فقط في الجدول.

بدلاً من ذلك، إذا تم تمرير --mask، يجب تحديد وسيط رقمي واحد، والذي يُفسّر كقناع قدرات ست عشري. في هذه الحالة، تُعرض فقط القدرات الموجودة في القناع في الجدول. هذا الوضع مخصص للمساعدة في فك ترميز مجموعات القدرات المتاحة عبر واجهات التنقِيح المختلفة (مثل "/proc/PID/status").

مثال 10. عرض بعض الأمثلة لأسماء القدرات

$ systemd-analyze capability 0 1 {30..32}
الاسم              الرقم
cap_chown              0
cap_dac_override       1
cap_audit_control     30
cap_setfcap           31
cap_mac_override      32

مثال 11. فك ترميز قناع قدرات استخرج من /proc

$ systemd-analyze capability -m 0000000000003c00
الاسم                 الرقم
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) لقائمة الشروط والتوكيدات (asserts) المتاحة.

مثال 12. تقييم الشروط التي تتحقق من إصدارات النواة

$ systemd-analyze condition 'ConditionVersion = ! <4.0' \


        'ConditionVersion = >=5.1' \


        'ConditionACPower=|false' \


        'ConditionArchitecture=|!arm' \


        'AssertPathExists=/etc/os-release'
test.service: AssertPathExists=/etc/os-release نُجح.
نُجحت التوكيدات.
test.service: ConditionArchitecture=|!arm نُجح.
test.service: ConditionACPower=|false فَشل.
test.service: ConditionVersion=>=5.1 نُجح.
test.service: ConditionVersion=!<4.0 نُجح.
نُجحت الشروط.

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 أدناه.

مثال 13. عرض الأيام الكبيسة في المستقبل القريب

$ systemd-analyze calendar --iterations=5 '*-2-29 0:0:0'


  الصيغة الأصلية: *-2-29 0:0:0
الصيغة القياسية: *-02-29 00:00:00


    الانقضاء التالي: Sat 2020-02-29 00:00:00 UTC


       من الآن: بقي 11 شهرًا و 15 يومًا


       تكرار. #2: Thu 2024-02-29 00:00:00 UTC


       من الآن: بقي 4 سنوات و 11 شهرًا


       تكرار. #3: Tue 2028-02-29 00:00:00 UTC


       من الآن: بقي 8 سنوات و 11 شهرًا


       تكرار. #4: Sun 2032-02-29 00:00:00 UTC


       من الآن: بقي 12 سنة و 11 شهرًا


       تكرار. #5: Fri 2036-02-29 00:00:00 UTC


       من الآن: بقي 16 سنة و 11 شهرًا

systemd-analyze timestamp TIMESTAMP...¶

يعالج هذا الأمر طابعًا زمنيًا (أي نقطة زمنية واحدة) ويخرج الصيغة القياسية والفرق بين هذا الطابع والآن. يجب أن يلتزم الطابع الزمني بالصيغة الموثقة في systemd.time(7)، قسم "PARSING TIMESTAMPS".

مثال 14. عرض معالجة الطوابع الزمنية

$ systemd-analyze timestamp yesterday now tomorrow


  الصيغة الأصلية: yesterday
الصيغة القياسية: Mon 2019-05-20 00:00:00 CEST


       (في UTC): Sun 2019-05-19 22:00:00 UTC


   ثواني يونكس: @15583032000


       من الآن: منذ يوم و 9 ساعات


  الصيغة الأصلية: now
الصيغة القياسية: Tue 2019-05-21 09:48:39 CEST


       (في UTC): Tue 2019-05-21 07:48:39 UTC


   ثواني يونكس: @1558424919.659757


       من الآن: منذ 43 ميكروثانية


  الصيغة الأصلية: tomorrow
الصيغة القياسية: Wed 2019-05-22 00:00:00 CEST


       (في UTC): Tue 2019-05-21 22:00:00 UTC


   ثواني يونكس: @15584760000


       من الآن: بقي 14 ساعة

systemd-analyze timespan EXPRESSION...¶

يعالج هذا الأمر فاصلًا زمنيًا (أي الفرق بين طابعين زمنيين) ويخرج الصيغة القياسية والقيمة المكافئة بالميكروثانية. يجب أن يلتزم الفاصل الزمني بالصيغة الموثقة في systemd.time(7)، قسم "PARSING TIME SPANS". تُعالج القيم التي لا تحتوي على وحدات كأنها ثوانٍ.

مثال 15. عرض معالجة الفواصل الزمنية

$ systemd-analyze timespan 1s 300s '1year 0.000001s'
الأصل: 1s


      ميكروثانية: 1000000


   بشري: 1s
الأصل: 300s


      ميكروثانية: 300000000


   بشري: 5min
الأصل: 1year 0.000001s


      ميكروثانية: 31557600000001


   بشري: 1y 1us

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

يشبه هذا الأمر systemctl cat، لكنه يعمل على ملفات الإعداد. سينسخ محتويات ملف الإعداد وأي ملحقات (drop-ins) إلى المخرج القياسي، مستخدمًا مجموعة أدلة وقواعد الأولوية المعتادة في systemd. يجب أن يكون كل معامل إما مسارًا مطلقًا يتضمن البادئة (مثل /etc/systemd/logind.conf أو /usr/lib/systemd/logind.conf)، أو اسمًا نسبيًا للبادئة (مثل systemd/logind.conf).

مثال 16. عرض إعدادات logind

$ systemd-analyze cat-config systemd/logind.conf
# /etc/systemd/logind.conf
...
[Login]
NAutoVTs=8
...
# /usr/lib/systemd/logind.conf.d/20-test.conf
... بعض التجاوزات من حزمة أخرى
# /etc/systemd/logind.conf.d/50-override.conf
... بعض تجاوزات المدير

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. في هذا النمط، لا تُطبع أي مخرجات. (وهذا يطابق العرف المستخدم في dpkg(1) --compare-versions.)

مثال 17. مقارنة إصدارات حزمة

$ 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=.

تُكتشف الأخطاء التالية حاليًا:

مثال 18. توجيهات مكتوبة بشكل خاطئ

$ cat ./user.slice
[Unit]
WhatIsThis=11
Documentation=man:nosuchfile(1)
Requires=different.service
[Service]
Description=x
$ systemd-analyze verify ./user.slice
[./user.slice:9] قيمة يسارية (lvalue) غير معروفة 'WhatIsThis' في القسم 'Unit'
[./user.slice:13] قسم غير معروف 'Service'. سيتم تجاهله.
خطأ: org.freedesktop.systemd1.LoadFailed:


   فشل تحميل الوحدة different.service:


   لا يوجد ملف أو دليل بهذا الاسم.
فشل إنشاء user.slice/start: معامل غير صالح
user.slice: فشل أمر man nosuchfile(1) بالرمز 16

مثال 19. وحدات خدمة مفقودة

$ tail ./a.socket ./b.socket
==> ./a.socket <==
[Socket]
ListenStream=100
==> ./b.socket <==
[Socket]
ListenStream=100
Accept=yes
$ systemd-analyze verify ./a.socket ./b.socket
الخدمة a.service لم تُحمل، ولا يمكن بدء a.socket.
الخدمة b@0.service لم تُحمل، ولا يمكن بدء b.socket.

مثال 20. تسمية وحدة باسم مستعار

$ cat /tmp/source
[Unit]
Description=Hostname printer
[Service]
Type=simple
ExecStart=/usr/bin/echo %H
MysteryKey=true
$ systemd-analyze verify /tmp/source
فشل تحضير اسم الملف /tmp/source: معامل غير صالح
$ systemd-analyze verify /tmp/source:alias.service
alias.service:7: اسم مفتاح غير معروف 'MysteryKey' في القسم 'Service'، سيتم تجاهله.

systemd-analyze security [UNIT...]¶

يحلل هذا الأمر إعدادات الأمان والعزل (sandboxing) لوحدة خدمة واحدة أو أكثر محددة. إذا حُدد اسم وحدة واحد على الأقل، فستُفحص إعدادات الأمان لوحدات الخدمة المحددة ويُعرض تحليل مفصل. إذا لم يُحدد اسم وحدة، فستُفحص جميع وحدات الخدمة المحملة حاليًا والتي تعمل لفترة طويلة ويُعرض جدول موجز بالنتائج. يتحقق الأمر من إعدادات الخدمة المتنوعة المتعلقة بالأمان، ويعين لكل منها قيمة رقمية لـ "مستوى التعرض"، اعتمادًا على مدى أهمية الإعداد. ثم يحسب مستوى التعرض الإجمالي للوحدة بأكملها، وهو تقدير في النطاق من 0.0 إلى 10.0 يشير إلى مدى تعرض الخدمة من الناحية الأمنية. تشير مستويات التعرض العالية إلى تطبيق عزل ضئيل للغاية. وتشير مستويات التعرض المنخفضة إلى عزل محكم وقيود أمنية قوية. لاحظ أن هذا يحلل فقط ميزات الأمان لكل خدمة التي ينفذها systemd نفسه. هذا يعني أن أي آليات أمان إضافية يطبقها كود الخدمة نفسه لا تُؤخذ في الحسبان. لا ينبغي إساءة فهم مستوى التعرض المحدد بهذه الطريقة: فمستوى التعرض العالي لا يعني عدم وجود عزل فعال يطبقه كود الخدمة نفسه، ولا يعني أن الخدمة معرضة فعليًا لهجمات عن بعد أو محلية. ومع ذلك، تشير مستويات التعرض العالية إلى أن الخدمة قد تستفيد على الأرجح من إعدادات إضافية تطبق عليها.

يرجى ملاحظة أنه يمكن التحايل على العديد من إعدادات الأمان والعزل بشكل فردي — ما لم تُدمج مع غيرها. على سبيل المثال، إذا احتفظت الخدمة بامتياز إنشاء أو إلغاء نقاط الوصل، فيمكن لكود الخدمة نفسه إلغاء العديد من خيارات العزل. وبناءً على ذلك، من الضروري أن تستخدم كل خدمة إعدادات العزل والأمان الأكثر شمولاً وصرامة قدر الإمكان. ستأخذ الأداة في الحسبان بعض هذه التوليفات والعلاقات بين الإعدادات، وليس كلها. لاحظ أيضًا أن إعدادات الأمان والعزل التي حُللت هنا تنطبق فقط على العمليات التي ينفذها كود الخدمة نفسه. إذا كان للخدمة وصول إلى نظام اتصال بين العمليات (IPC) (مثل D-Bus)، فقد تطلب عمليات من خدمات أخرى لا تخضع لنفس القيود. وبالتالي، فإن أي تحليل شامل للأمان والعزل يكون غير مكتمل إذا لم تُوثق سياسة الوصول إلى IPC أيضًا.

مثال 21. تحليل systemd-logind.service

$ systemd-analyze security --no-pager systemd-logind.service


  الاسم                الوصف                                    التعرض
✗ PrivateNetwork=     للخدمة وصول إلى شبكة المضيف              0.5
✗ User=/DynamicUser=  تعمل الخدمة كمستخدم جذر (root)            0.4
✗ DeviceAllow=        ليس للخدمة قائمة وصول (ACL) للأجهزة        0.2
✓ IPAddressDeny=      تحظر الخدمة جميع نطاقات عناوين IP
...
→ مستوى التعرض الإجمالي لخدمة systemd-logind.service: 4.1 حسناً 🙂

systemd-analyze inspect-elf FILE...¶

سيحمل هذا الأمر الملفات المحددة، وإذا كانت كائنات ELF (ملفات تنفيذية، مكتبات، ملفات اللب (core files)، إلخ.) فسيقوم بمعالجة البيانات الوصفية للحزم المضمنة، إن وجدت، ويطبعها في جدول أو بتنسيق json. انظر وثيقة Package Metadata for Executable Files[1] لمزيد من المعلومات.

مثال 22. طبع معلومات حول ملف لب (core file) بتنسيق JSON

$ systemd-analyze inspect-elf --json=pretty \


        core.fsverity.1000.f77dac5dc161402aa44e15b7dd9dcf97.58561.1637106137000000
{


        "elfType" : "coredump",


        "elfArchitecture" : "AMD x86-64",


        "/home/bluca/git/fsverity-utils/fsverity" : {


                "type" : "deb",


                "name" : "fsverity-utils",


                "version" : "1.3-1",


                "buildId" : "7c895ecd2a271f93e96268f479fdc3c64a2ec4ee"


        },


        "/home/bluca/git/fsverity-utils/libfsverity.so.0" : {


                "type" : "deb",


                "name" : "fsverity-utils",


                "version" : "1.3-1",


                "buildId" : "b5e428254abf14237b0ae70ed85fffbb98a78f88"


        }
}

systemd-analyze dlopen-metadata FILE¶

سيحمل هذا الأمر الملف المحدد، وإذا كان كائن ELF (ملفات تنفيذية، مكتبات، ملفات اللب، إلخ.) فسيقوم بمعالجة البيانات الوصفية لـ dlopen المضمنة، إن وجدت، ويطبعها في جدول أو بتنسيق json. انظر وثيقة dlopen() Metadata for ELF Files[2] لمزيد من المعلومات.

systemd-analyze fdstore UNIT...¶

يسرد المحتويات الحالية لمخزن واصفات الملفات لوحدة الخدمة المحددة. يعرض هذا الأسماء، وأنواع العقد (inodes)، وأرقام الأجهزة، وأرقام العقد، والمسارات وأنماط الفتح لواصفات الملفات المفتوحة. يجب أن يكون لدى الوحدات المحددة خيار FileDescriptorStoreMax= مفعلاً، انظر systemd.service(5) للمزيد من التفاصيل.

مثال 23. مخرج الجدول

$ 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" إلى الأرقام الكبرى/الصغرى (major/minor) لعقدة الجهاز التي تدعم نظام الملفات الذي توجد عليه عقدة (inode) واصف الملف. يشير عمود "RDEVNO" إلى الأرقام الكبرى/الصغرى لعقدة الجهاز نفسها إذا كان واصف الملف يشير إلى إحداها. قارن ذلك بحقول .st_dev و .st_rdev المقابلة في struct stat (انظر stat(2) للتفاصيل). أرقام العقد المدرجة في عمود "INODE" موجودة على نظام الملفات المشار إليه بواسطة "DEVNO".

systemd-analyze image-policy POLICY...¶

يحلل هذا الأمر سلسلة سياسة الصورة المحددة، وفقًا لـ systemd.image-policy(7). تُجعل السياسة قياسية ومبسطة. لكل معرف قسم محدد حاليًا (وفقًا لـ UAPI.2 Discoverable Partitions Specification[3]) يُعرض تأثير سلسلة سياسة الصورة في شكل جدول.

مثال 24. مثال للمخرج

$ systemd-analyze image-policy swap=encrypted:usr=read-only-on+verity:root=encrypted
تحليل السياسة: root=encrypted:usr=verity+read-only-on:swap=encrypted


       الصيغة الطويلة: 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، وكان مدعومًا، ومستخدمًا من قبل البرامج الثابتة (firmware)، ومشغلات نواة نظام التشغيل ومساحة المستخدم (أي systemd)، فسيطبع هذا "yes" ويخرج بحالة خروج صفرية. إذا لم يُكتشف/يُدعم/يُستخدم مثل هذا الجهاز، يطبع "no". خلاف ذلك، يطبع "partial". وفي أي من هاتين الحالتين يخرج بحالة خروج غير صفرية. كما يعرض خمسة أسطر تشير بشكل منفصل عما إذا كانت البرمجيات الثابتة والمشغلات والنظام والنواة والمكتبات قد اكتشفت/دعمت/استخدمت TPM2. حاليًا، المكتبات المطلوبة هي libtss2-esys.so.0 و libtss2-rc.so.0 و libtss2-mu.so.0. قد يتغير هذا المتطلب في الإصدارات المستقبلية.

لاحظ أن هذا يتحقق من أجهزة TPM 2.0 فقط، ولا يأخذ TPM 1.2 في الحسبان على الإطلاق.

ادمجه مع --quiet لكتم المخرج.

مثال 25. مثال للمخرج

yes
+firmware
+driver
+system
+subsystem
+libraries


  +libtss2-esys.so.0


  +libtss2-rc.so.0


  +libtss2-mu.so.0

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

systemd-analyze identify-tpm2¶

يعرض معلومات المورد حول جهاز TPM 2.0 الذي اكتُشف.

مثال 26. مثال للمخرج

  Family Indicator: 2.0


             Level: 0


          Revision: 1.59
Specification Date: Mon 2023-01-09


      Manufacturer: STM


     Vendor String: ST33KTPM2XSPI


  Firmware Version: 9.258


   Modalias String: fi2.0:lv0:rv1.59:sy2023:sd9:mfSTM:vsST33KTPM2XSPI:ty0:fw9.258.0:

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

systemd-analyze pcrs [PCR...]¶

يعرض هذا الأمر سجلات PCR الخاصة بـ TPM2 المعروفة مع أسمائها التعريفية وقيمها الحالية.

مثال 27. مثال للمخرج

$ 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 nvpcrs [NVPCR...]¶

يعرض هذا الأمر سجلات NvPCR الخاصة بـ TPM2 المعروفة (سجلات PCR إضافية مخزنة في فهارس TPM2 NV) مع أسمائها التعريفية وقيمها الحالية.

مثال 28. مثال للمخرج

$ systemd-analyze nvpcrs
الاسم         فهرس NV  القيمة
cryptsetup 0x1d10201 f400543943cc7215557ce672872ace5382e6d53177cc459078ba9277e41588d9
hardware   0x1d10200 e155474936d7d74c893e6ece1099a2311d572cf23becea159dabf282db754284

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

systemd-analyze srk [>FILE]¶

يقرأ هذا الأمر مفتاح جذر التخزين (SRK) من جهاز TPM2، ويكتبه بتنسيق TPM2B_PUBLIC المرتب (marshalled) إلى المخرج القياسي (stdout). المخرج عبارة عن بيانات غير قابلة للطباعة، لذا يجب إعادة توجيهه إلى ملف أو إلى أنبوب.

مثال 29. حفظ مفتاح جذر التخزين في srk.tpm2b_public

systemd-analyze srk >srk.tpm2b_public

systemd-analyze architectures [NAME...]¶

يسرد جميع معماريات وحدة المعالجة المركزية (CPU) المعروفة، وأيها أصلي (native). أسماء المعماريات المدرجة هي تلك التي يدعمها ConditionArchitecture=، انظر systemd.unit(5) للتفاصيل. إذا حُددت أسماء معماريات، فستُسرد المعماريات المحددة فقط.

المثال 30. خرج الجدول

$ systemd-analyze architectures
الاسم        الدعم
alpha       أجنبي
arc         أجنبي
arc-be      أجنبي
arm         أجنبي
arm64       أجنبي
...
sparc       أجنبي
sparc64     أجنبي
tilegx      أجنبي
x86         ثانوي
x86-64      أصيل

systemd-analyze smbios11¶

يعرض قائمة بسلاسل SMBIOS من النوع #11 الممررة إلى النظام. انظر أيضًا smbios-type-11(7).

المثال 31. مثال للخرج

$ 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 من النوع #11.

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

systemd-analyze chid¶

يعرض قائمة بمعرفات عتاد الحاسوب (CHIDs) للنظام المحلي. تحدد هذه المعرفات عتاد حاسوب النظام، بناءً على بيانات SMBIOS. انظر استخدام معرفات عتاد الحاسوب (CHIDs)[4] للمزيد من التفاصيل حول CHIDs.

المثال 32. مثال للخرج

$ systemd-analyze chid
النوع المدخل  CHID


   3 MFPSmp 520537c0-3b59-504f-b062-9682ea236b21


   4 MFPS-- edf05dc8-a53d-5b2c-8023-630bca2a2463


   5 MFP--- ebc6a4d9-ec48-537a-916b-c69fa4fdd814


   6 M--Smp 5ebe4bba-f598-5e90-9ff2-9fd0d3211465


   7 M--S-- 1a3fb835-b42a-5f9c-a38c-eff5bfd5c41d


   8 M-P-mp 2a831dce-8163-5bad-8406-435b8c752dd8


   9 M-P--- 7c21c878-4a75-50f7-9816-21e811588da0


  10 MF--mp 9a003537-bcc5-500e-b10a-8d8892e4fc64


  11 MF---- bb9122bb-8a5c-50d2-a742-a85beb719909


  13 M---mp bfc36935-5032-5987-a0a3-6311f01de33a
أسطورة: M ← sys_vendor (LENOVO) ┄ F ← product_family (ThinkPad X1 Carbon Gen 9) ┄ P ← product_name (20XW0055GE)


        S ← product_sku (LENOVO_MT_20XW_BU_Think_FM_ThinkPad X1 Carbon Gen 9) ┄ m ← board_vendor (LENOVO)


        p ← board_name (20XW0055GE)

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

systemd-analyze transient-settings النوع...¶

يسرد الخصائص التي يمكن ضبطها لأنواع الوحدات المختلفة عبر واجهات سطر الأوامر، لا سيما خياري systemctl(1) set-property و --property=/--automount-property= في systemd-run(1)، و systemd-nspawn(1)، و systemd-mount(1). هذه التعيينات ممكنة لمجموعة فرعية من الخصائص التي يمكن ضبطها في ملفات التهيئة، انظر systemd.unit(5)، و systemd.exec(5)، و systemd.resource-control(5)، وصفحات أنواع الوحدات النوعية الأخرى. يجب أن يكون وسيط النوع نوع وحدة ("service"، "socket"، ...). تُسرد الخصائص التي تنطبق على الأنواع المحددة.

ملاحظة: تشكل خصائص D-Bus الموثقة في org.freedesktop.systemd1(5) مجموعة تتداخل جزئيًا مع القوائم التي يولدها هذا الأمر. تشترك العديد من خصائص D-Bus والإعدادات العابرة في نفس الأسماء، ولكن على سبيل المثال، LogRateLimitIntervalSec= موصوف في systemd.exec(5) وسيُسرد بواسطة هذا الأمر، لكن خاصية D-Bus المقابلة الموصوفة في systemd.exec(5) هي LogRateLimitIntervalUSec.

هذا الفعل مخصص أساسًا للتوليد البرمجي لإكمال الصدفة.

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

systemd-analyze unit-shell الخدمة [أمر...]¶

يعمل الأمر المعطى في مساحة أسماء الخدمة المحددة التي تعمل حاليًا. إذا لم يُعطَ أي أمر، فستُطلق وتُلحق صدفة بمساحة الأسماء الخاصة بالخدمة.

المثال 33. مثال للخرج

$ systemd-analyze unit-shell systemd-resolved.service ls
bin   dev  etc	   home  lib	lib64	lost+found  mnt  proc  run   srv  tmp  var	vmlinuz.old
boot  efi  exitrd  init  lib32	libx32	media	    opt  root  sbin  sys  usr  vmlinuz	work

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

systemd-analyze unit-gdb الخدمة¶

يُطلق ويُلحق منقح بالخدمة المعطاة. بشكل مبدئي، سيُستخدم gdb(1). يمكن تغيير هذا باستخدام خيار --debugger= أو متغير البيئة $SYSTEMD_DEBUGGER. استخدم خيار --debugger-arguments= لتمرير وسائط سطر أوامر إضافية إلى المنقح واقتبسها بشكل مناسب عندما تحتوي الوسائط على مسافات بيضاء (انظر المثال).

المثال 34. 

$ systemd-analyze --debugger-arguments="-batch -ex 'info all-registers'" unit-gdb systemd-oomd.service

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