البحث في الموقع

يتكوّن نظام التمهيد systemd من مجموعة من الأدوات التي تمثّل منصة مركزية لإدارة نظام لينكس وإعداده. تُستخدم أداة systemctl للتحكّم في systemd وإدارة الخدمات المرتبطة به. يهدف هذا المقال إلى إلقاء الضوء على كيفية إدارة النظام والخدمات على نظام تشغيل يستخدم systemd للتمهيد. أساسيات systemd وsystemctl التحقق من أن systemd مثبّت وإصداره: $ systemd --version systemd 229 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN يظهر من المثال أعلاه أن نظام التمهيد systemd مثبت وأن لدينا الإصدار 229. التحقق من مكان تواجد الملفات التنفيذية والمكتبات البرمجية الخاصّة بـ وsystemctl: $ whereis systemd systemd: /usr/lib/systemd /bin/systemd /etc/systemd /lib/systemd /usr/share/systemd /usr/share/man/man1/systemd.1.gz $ whereis systemctl systemctl: /bin/systemctl /usr/share/man/man1/systemctl.1.gz التحقق من حالة عمل systemd يمكن استخدام الأمر ps لسرد العمليات Processes النشطة ثم عزل تلك المتعلقة بـsystemd، وذلك على النحو التالي: $ ps -eaf | grep [s]ystemd root 1000 1 0 12:23 ? 00:00:00 /lib/systemd/systemd-journald root 1029 1 0 12:23 ? 00:00:00 /lib/systemd/systemd-udevd systemd+ 2639 1 0 12:23 ? 00:00:00 /lib/systemd/systemd-timesyncd message+ 2781 1 0 12:23 ? 00:00:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation root 2862 1 0 12:23 ? 00:00:00 /lib/systemd/systemd-logind sddm 3284 1 0 12:23 ? 00:00:00 /lib/systemd/systemd --user academy 3532 1 0 12:25 ? 00:00:00 /lib/systemd/systemd --user تحمل عمليّة systemd المعرِّف 1. استخدمنا الخيار e- مع الأمر ps لسرد جميع العمليات، ثم حدّدنا العمليات التي لا ترأس جلسة Session leaders (العمليات التي يساوي معرّف العمليّة السّلف Parent Id معرّفَ الجلسة Session Id). استخدمنا الخيار f- لتهيئة مخرجات الأمر التي طبّقنا عليه الأمر grep لتحديد تلك التي توافق التعبير النمطي s]ystemd]. تحليل متتالية الإقلاع في systemd تُستخدَم أداة systemd-analyze لتحليل متتالية الإقلاع: $ systemd-analyze Startup finished in 9.314s (firmware) + 2.897s (loader) + 9.290s (kernel) + 46.672s (userspace) = 1min 8.175s نضيف المعطى blame للأمر أعلاه من أجل الحصول على الوقت الذي استغرقته كل خدمة للإقلاع: $ systemd-analyze blame 40.880s systemd-suspend.service 25.010s apt-daily.service 14.173s dev-sda7.device 10.530s dnsmasq.service 10.228s click-system-hooks.service 7.909s accounts-daemon.service 7.908s ModemManager.service 7.120s NetworkManager-wait-online.service 7.084s gpu-manager.service (...) يمكن أيضا تحليل الوقت المستغرق للعمليات الحرجة باستخدام المعطى critical-chain الذي يطبع شجرة بتتالي العمليات التي تنتظر بقية العمليات إقلاعها: $ systemd-analyze critical-chain The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. graphical.target @41.348s └─multi-user.target @41.348s └─apache2.service @34.735s +6.612s └─network-online.target @34.717s └─NetworkManager-wait-online.service @27.596s +7.120s └─NetworkManager.service @21.672s +5.913s └─dbus.service @21.471s └─basic.target @21.470s └─sockets.target @21.470s └─snapd.socket @21.441s +17ms └─sysinit.target @21.391s └─apparmor.service @20.785s +605ms └─local-fs.target @20.772s └─run-user-123.mount @35.991s └─local-fs-pre.target @15.110s └─systemd-remount-fs.service @15.038s +27ms └─systemd-journald.socket @3.530s └─-.slice @3.497s تظهر بعد علامة @ المدة التي فُعلت بعدها الوحدة، في ما يظهر الوقت الذي استغرقته الوحدة للإقلاع بعد علامة +. يمكن تمرير اسم وحدة إلى الأمر أعلاه لقصر السّرد على العمليات التي تنتظر الوحدة إقلاعها: $ systemd-analyze critical-chain apache2.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. └─network-online.target @35.533s └─NetworkManager-wait-online.service @29.424s +6.108s └─NetworkManager.service @22.174s +7.234s └─dbus.service @20.998s └─basic.target @20.976s └─sockets.target @20.976s └─snapd.socket @20.919s +46ms └─sysinit.target @20.902s └─apparmor.service @19.691s +1.193s └─local-fs.target @19.681s └─run-user-123.mount @37.402s └─local-fs-pre.target @14.915s └─systemd-remount-fs.service @14.866s +32ms └─system.slice @3.541s └─-.slice @3.508s سرد الوحدات يعمل الأمر systemctl عند استخدام المعطى list-unit-files على سرد قائمة بجميع الوحدات الموجودة في النظام: $ systemctl list-unit-files UNIT FILE STATE proc-sys-fs-binfmt_misc.automount static org.freedesktop.hostname1.busname static org.freedesktop.locale1.busname static org.freedesktop.login1.busname static org.freedesktop.network1.busname static org.freedesktop.resolve1.busname static org.freedesktop.systemd1.busname static org.freedesktop.timedate1.busname static dev-hugepages.mount static dev-mqueue.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static acpid.path enabled cups.path enabled (...) ملحوظة: يمكن للوحدة أن تكون خدمة، نقطة تركيب Mount point، مقبس شبكة Socket أو جهازا طرفيا Device. يمكنك الاقتصار على الوحدات العاملة حاليا بالمعطى list-units: $ systemctl list-units UNIT LOAD ACTIVE SUB DESCRIPTION proc-sys-fs-binfmt_misc.automount loaded active running Arbitrary Executable File Formats File System Automoun sys-devices-pci0000:00-0000:00:02.0-drm-card0-card0\x2deDP\x2d1-intel_backlight.device loaded active plugged /sys/devices/pci0000: sys-devices-pci0000:00-0000:00:03.0-sound-card0.device loaded active plugged Broadwell-U Audio Controller sys-devices-pci0000:00-0000:00:14.0-usb1-1\x2d3-1\x2d3:1.0-net-enx582c80139263.device loaded active plugged E353/E3131 sys-devices-pci0000:00-0000:00:14.0-usb1-1\x2d4-1\x2d4:1.0-bluetooth-hci0.device loaded active plugged /sys/devices/pci0000:00/000 sys-devices-pci0000:00-0000:00:1b.0-sound-card1.device loaded active plugged Wildcat Point-LP High Definition Audio Controller (…) كما يمكن عزل الوحدات التي أخفقت بالمعطى failed--: $ systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● snapd.refresh.service loaded failed failed Automatically refresh installed snaps ● systemd-suspend.service loaded failed failed Suspend LOAD = Reflects whether the unit definition was properly loaded. ACTIVE = The high-level unit activation state, i.e. generalization of SUB. SUB = The low-level unit activation state, values depend on unit type. 2 loaded units listed. Pass --all to see loaded but inactive units, too. To show all installed unit files use 'systemctl list-unit-files'. التحقق من تفعيل خدمة يطلُب الأمر التالي التحقق من أن خدمة الجدولة Cron مفعَّلة (تعمل مع إقلاع النظام): $ systemctl is-enabled cron.service enabled يظهر من نتيجة الأمر أن الخدمة مفعَّلة enabled. التحقق من حالة خدمة نتحقق في الأمر التالي من حالة الخدمتين mysql وapache2: systemctl status apache2.service ● apache2.service - LSB: Apache2 web server Loaded: loaded (/etc/init.d/apache2; bad; vendor preset: enabled) Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: active (running) since Wed 2016-09-14 12:23:56 GMT; 4h 31min ago يظهر في نتيجة تنفيذ الأمرين أعلاه أن mysql غير مفعَّلة وليست نشطة أثناء تنفيذ الأمر؛ أما الخدمة apache2 فهي مفعَّلة وتعمل منذ أربع ساعات. التحكم في الخدمات وإداراتها بـ systemctl سرد جميع الخدمات يسرُد الأمر التالي جميع خدمات النظام بغضّ النظر عن حالتها (مفعَّلة أو معطَّلة): $ systemctl list-unit-files --type=service UNIT FILE STATE accounts-daemon.service enabled acpid.service disabled apport-forward@.service static apt-daily.service static atd.service enabled autovt@.service enabled bootlogd.service masked bootlogs.service masked bootmisc.service masked cgmanager.service enabled cgproxy.service enabled checkfs.service masked checkroot-bootclean.service masked checkroot.service masked (...) تشغيل خدمة (apache2)، إيقافها، إعادة تشغيلها أو إعادة تحميلها: تبدأ الأوامر التالية تشغيل الخدمة apache2، تعيد تحميلها، تعيد تشغيلها وتوقفها على التوالي (تحتاج لصلاحيات إدارية): # sudo systemctl start apache2 # sudo systemctl restart apache2 # sudo systemctl stop apache2 # sudo systemctl reload apache2 apache2.service is not active, cannot reload. # sudo systemctl start apache2 # sudo systemctl reload apache2 # sudo systemctl status apache2 ● apache2.service - LSB: Apache2 web server Loaded: loaded (/etc/init.d/apache2; bad; vendor preset: enabled) Drop-In: /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: active (running) since Wed 2016-09-14 17:15:11 GMT; 17s ago لا تُظهر الأوامر أعلاه مخرجات عند تنفيذها بدون مشاكل. استخدم أمر التحقق status لمعرفة حالة الخدمة. تفعيل خدمة أو تعطيلها تُسمّى الخدمات التي تبدأ بالعمل مع إقلاع النظام بالخدمات المفعَّلة Enabled، وعكسُها الخدمات المعطّلة Disabled. أما الخدمات النشطة Active فهي الخدمات العاملة حاليا (تُشغَّل بالأمر start). يستفسر الأمر التالي عن نشاط الخدمة apache2 (تعمل أم لا): $ systemctl is-active apache2.service active نستخدم الأمر disable لتعطيل خدمة وenable لتفعيلها: # systemctl enable apache2.service # systemctl disable apache2.service إخفاء خدمة يمنع الإخفاء Masking تشغيل خدمة. يمكن إخفاء الخدمة apache2 على النحو التالي: # systemctl mask apache2.service Created symlink from /etc/systemd/system/apache2.service to /dev/null. ولإلغاء الإخفاء: $ sudo systemctl unmask apache2.service Removed symlink /etc/systemd/system/apache2.service. الإيقاف الإجباري لخدمة بـsystemctl # systemctl kill apache2 # sudo systemctl status apache2 ● apache2.service - LSB: Apache2 web server Loaded: loaded (/etc/init.d/apache2; bad; vendor preset: enabled) Drop-In: /etc/systemd/system/apache2.service.d └─50-CPUShares.conf /lib/systemd/system/apache2.service.d └─apache2-systemd.conf Active: inactive (dead) Docs: man:systemd-sysv-generator(8) التحكم في نقاط التركيب وإداراتها بـsystemctl سرد جميع نقاط التركيب في النظام $ systemctl list-unit-files --type=mount UNIT FILE STATE dev-hugepages.mount static dev-mqueue.mount static proc-sys-fs-binfmt_misc.mount static sys-fs-fuse-connections.mount static sys-kernel-config.mount static sys-kernel-debug.mount static tmp.mount disabled 7 unit files listed. إدارة نقاط التركيب يمكن بالأوامر التالية تشغيل نقطة تركيب، فصلها، إعادة تركيبها والتحقق من حالتها على التوالي: # systemctl start tmp.mount # systemctl stop tmp.mount # systemctl restart tmp.mount # systemctl reload tmp.mount # systemctl status tmp.mount tmp.mount - Temporary Directory Loaded: loaded (/usr/lib/systemd/system/tmp.mount; disabled) Active: active (mounted) since Wed 2016-09-14 17:36:11 GMT;; 2min 48s ago Where: /tmp What: tmpfs (...) تفعيل نقطة تركيب أو تعطيلها يمكن بطريقة مشابهة للخدمات تفعيل نقاط التركيب أوتعطيلها: # systemctl enable tmp.mount # systemctl disable tmp.mount إخفاء نقطة تركيب يُستخدَم الأمر mask لإخفاء نقطة تركيب على النحو التالي: # systemctl mask tmp.mount Created symlink from /etc/systemd/system/tmp.mount to /dev/null. ولإلغاء الإخفاء: # systemctl unmask tmp.mount Removed symlink /etc/systemd/system/tmp.mount التحكّم في مقابس الشبكة بـsystemctl سرد جميع المقابس $ systemctl list-unit-files --type=socket UNIT FILE STATE acpid.socket enabled apport-forward.socket enabled avahi-daemon.socket enabled cups.socket enabled dbus.socket static lxd.socket masked saned.socket disabled snapd.socket enabled syslog.socket static systemd-bus-proxyd.socket static systemd-fsckd.socket static systemd-initctl.socket static systemd-journald-audit.socket static systemd-journald-dev-log.socket static systemd-journald.socket static systemd-networkd.socket disabled systemd-rfkill.socket static systemd-udevd-control.socket static systemd-udevd-kernel.socket static uuidd.socket enabled 20 unit files listed. تشغيل مقبس (cups)، إعادة تشغيله، إعادة تحميله أو إيقافه: # systemctl start cups.socket # systemctl restart cups.socket # systemctl reload cups.socket # systemctl stop cups.socket $ systemctl status cups.socket ● cups.socket - CUPS Scheduler Loaded: loaded (/lib/systemd/system/cups.socket; enabled; vendor preset: enabled) Active: active (listening) since Thu 2016-09-15 14:39:47 GMT; 5s ago Listen: /var/run/cups/cups.sock (Stream) تفعيل مقبس أو تعطيله: # systemctl enable cups.socket # systemctl disable cups.socket إخفاء مقبس $ sudo systemctl mask cups.socket Created symlink from /etc/systemd/system/cups.socket to /dev/null. $ sudo systemctl unmask cups.socket Removed symlink /etc/systemd/system/cups.socket. استخدام المعالج حصة خدمة من المعالج يمكن استخدام systemctl لعرض عدد الحصص الحاليّة المحدّدة لخدمة من المعالج: # systemctl show -p CPUShares apache2.service CPUShares=18446744073709551615 تعرّف قيمة CPUShares الوقت المخصّص للخدمة من المعالج. تعني زيادة هذه القيمة الرفع من أولويّة للخدمة. يمكن تحديد الحصّة بتغيير قيمة المتغيّر على النحو التالي: # systemctl set-property apache2.service CPUShares=1500 $ systemctl show -p CPUShares apache2.service CPUShares=1500 ينشئ النظام عند تحديد حصّة خدمة مجلّدا يوافق اسمه اسمَ الخدمة (مثلا apache2.service.d) وينشئ بداخله ملف إعداد يبدأ برقم يتبعه اسم المتغيّر (مثلا 50-CPUShares.conf): $ cat /etc/systemd/system/apache2.service.d/50-CPUShares.conf [Service] CPUShares=1500 عرض تفاصيل الإعداد الخاصّة بخدمة $ systemctl show apache2 Type=forking Restart=no NotifyAccess=none RestartUSec=100ms TimeoutStartUSec=5min TimeoutStopUSec=5min RuntimeMaxUSec=infinity WatchdogUSec=0 WatchdogTimestampMonotonic=0 FailureAction=none PermissionsStartOnly=no RootDirectoryStartOnly=no RemainAfterExit=no GuessMainPID=no MainPID=0 ControlPID=0 FileDescriptorStoreMax=0 NFileDescriptorStore=0 StatusErrno=0 (...) عرض اعتماديّات خدمة $ systemctl list-dependencies apache2.service apache2.service ● ├─system.slice ● ├─network-online.target ● │ ├─networking.service ● │ └─NetworkManager-wait-online.service ● └─sysinit.target ● ├─apparmor.service ● ├─brltty.service ● ├─console-setup.service ● ├─dev-hugepages.mount ● ├─dev-mqueue.mount ● ├─friendly-recovery.service ● ├─keyboard-setup.service ● ├─kmod-static-nodes.service ● ├─plymouth-read-write.service ● ├─plymouth-start.service ● ├─proc-sys-fs-binfmt_misc.automount ● ├─resolvconf.service ● ├─setvtrgb.service (...) سرد مجموعات التحكّم Control groups يُستخدَم الأمر systemd-cgls لسرد مجموعات التحكّم هرميّا على النحو التالي: # systemd-cgls ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 21 ├─user.slice │ └─user-1000.slice │ └─session-1.scope │ ├─ 2292 gdm-session-worker [pam/gdm-password] │ ├─ 2308 /usr/bin/gnome-keyring-daemon --daemonize --login │ ├─ 2351 gnome-session --session gnome-classic │ ├─ 2358 dbus-launch --sh-syntax --exit-with-session │ ├─ 2359 /bin/dbus-daemon --fork --print-pid 4 --print-address 6 --sessi... │ ├─ 2424 /usr/libexec/gvfsd │ ├─ 2428 /usr/libexec/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes يُمكن سرد هذه المجموعات حسب استخدام المعالج والذاكرة العشوائية أو حسب المُدخَلات والمُخرجات بالأمر systemd-cgtop: Path Tasks %CPU Memory Input/s Output/s / 216 37.7 1.6G - - /system.slice - 7.1 - - - /system.slice/gdm.service 2 7.1 - - - /system.slice/rngd.service 1 0.0 - - - /system.slice/tuned.service 1 0.0 - - - /system.slice/vboxadd-service.service 1 0.0 - - - /system.slice/httpd.service 6 0.0 - - - التحكم في مستويات التشغيل Runlevels الإقلاع في وضع الإنقاذ Rescue mode أو وضع الطوارئ Emergency mode يمكن في حال حدوث مشكل الإقلاعُ في وضع الإنقاذ بالأمر التالي: # systemctl rescue كما يُستخدم الأمر systemctl للإقلاع في وضع الطوارئ: # systemctl emergency وللعودة إلى وضع الإقلاع المبدئي: # systemctl default عرض مستوى التشغيل الحالي $ systemctl get-default graphical.target الإقلاع على مستوى تشغيل يمكن تحديد مستوى التشغيل الذي نريد الإقلاع عليه بالأمر systemctl isolate؛ مثلا: # systemctl isolate runlevel5.target # systemctl isolate runlevel3.target أو بذكر اسم المستوى: # systemctl isolate graphical.target # systemctl isolate multiuser.target تعيين مستوى التشغيل المبدئي # systemctl set-default runlevel3.target # systemctl set-default runlevel5.target مستويات التشغيل هي التالية: المستوى 0 runlevel0: إيقاف تشغيل النظام وفصله عن الطاقة. المستوى 1 runlevel1: وضع الإنقاذ والصيانة. المستوى 2 runlevel2: تعدّد المستخدمين. المستوى 3 runlevel3: تعدّد المستخدمين مع تشغيل خدمات الشبكة. المستوى 4 runlevel4: مستوى تشغيل محجوز لما يعرّفه المستخدم. المستوى 5 runlevel5: المستوى 3 + واجهة رسومية. المستوى 6 runlevel6: إعادة تشغيل النظام. إعادة تشغيل النظام، إيقافه، تعليقه وإسباته # systemctl reboot # systemctl halt # systemctl suspend # systemctl hibernate كما يمكن جعل النظام في وضع السبات المزدوج (مزيج من وضع السبات والتعليق) بالأمر: # systemctl hybrid-sleep ترجمة - بتصرّف - لمقال How to Manage ‘Systemd’ Services and Units Using ‘Systemctl’ in Linux.

شهدت السنوات الأخيرة انتقال توزيعات لينِكس على نحو متزايد من أنظمة init الأخرى إلى systemd، تُوفِّر مجموعة أدوات systemd نموذج init مرن وسريع لإدارة الجهاز بشكل كامل من الإقلاع boot فصاعدًا. سنقوم في هذا الدرس بالمرور بشكل سريع على أهم الأوامر التي نحتاج معرفتها لإدارة خادوم يحتوي على systemd، ينبغي أن يعمل هذا على أي خادوم يُطبِّق systemd (أي إصدار نظام تشغيل يساوي أو أعلى من Ubuntu 15.04, Debian 8, CentOS 7, Fedora 15). فلنبدأ الآن. إدارة الوحدة بشكل أساسي Basic Unit Management الشيء الأساسي الذي يديره systemd ويعمل عليه هو الوحدة “unit”، يُمكن أن تكون الوحدات من عدّة أنواع، ولكن النّوع الأشيع هو الخدمة service (يتبيّن ذلك من ملف الوحدة الذي ينتهي بـ .service)، ولإدارة الخدمات على خادوم يحتوي systemd فإنّ أداتنا الرئيسيّة هي الأمر systemctl. تمتلك جميع أوامر نظام init الاعتياديّة إجراءات مُكافِئة مع الأمر systemctl، سنستخدم الوحدة nginx.service للتوضيح (يجب علينا تثبيت Nginx باستخدام مُدير الحِزَم للحصول على ملف الخدمة هذا). نستطيع على سبيل المثال تشغيل الخدمة بكتابة ما يلي: sudo systemctl start nginx.service نستطيع إيقافها مرّة أخرى بكتابة: sudo systemctl stop nginx.service ولإعادة تشغيل الخدمة نكتب: sudo systemctl restart nginx.service ولمحاولة إعادة تحميل reload الخدمة بدون مقاطعة الوظيفة الطبيعيّة نكتب ما يلي: sudo systemctl reload nginx.service تمكين أو تعطيل الوحدات لا يتم بشكل افتراضي تشغيل معظم ملفّات وحدات systemd تلقائيًّا عند الإقلاع، ولإعداد هذه الوظيفة نحتاج لتمكين “enable” الوحدة، والذي يقوم بتعليقها بخطافة hook إلى هدف “target” إقلاع مُعيَّن ممّا يُسبِّب تحفيز تشغيلها عند بدء تشغيل الهدف. لتمكين خدمة من البدء تلقائيًّا عند الإقلاع نكتب: sudo systemctl enable nginx.service إن كُنّا نرغب بتعطيل الخدمة مرّة أخرى نكتب: sudo systemctl disable nginx.service الحصول على لمحة عامة عن حالة النظام هناك قدر كبير من المعلومات التي يمكننا استخلاصها من خادوم systemd للحصول على لمحة عامّة عن حالة النّظام. على سبيل المثال للحصول على كافّة ملفّات الوحدات التي يعرضها systemd على أنّها نشطة “active” نكتب ما يلي (نستطيع فعليًّا ألّا نكتب list-units لأنّه سلوك systemctl الافتراضي): systemctl list-units ولعرض جميع الوحدات التي قام systemd بتحميلها أو حاول تحميلها إلى الذّاكرة بما في ذلك الخدمات غير النشطة حاليًّا نُضيف المحوِّل switch الذي يُدعى all--: systemctl list-units --all لعرض جميع الوحدات المُثبَّتة على النّظام بما في ذلك الوحدات التي لم يحاول systemd أن يُحمّلها إلى الذاكرة نكتب: systemctl list-unit-files عرض معلومات السجل Log الأساسية يجمع ويدير المُكوِّن في systemd الذي يُدعى journald المُدخلات اليوميّة journal entries من كافّة أجزاء النّظام. وهي بالأساس معلومات السّجلات من التطبيقات والنواة kernel. ولمشاهدة جميع مُدخلات السّجلات بدءًا من المُدخَل الأقدم نكتب: journalctl سيظهر لنا هذا افتراضيًّا المُدخلات من الإقلاعات السّابقة والحاليّة إن تمّ إعداد journald ليحفظ سجلّات records الإقلاع السّابق، تُمكِّن بعض التوزيعات هذا الأمر افتراضيًّا بينما لا تقوم توزيعات أخرى بتمكينه (ولتمكينه إمّا نُحرِّر الملف etc/systemd/journald.conf/ ونُعيِّن الخيار Storage= إلى مستمر "persistent" أو نُنشِئ الدّليل persistent بكتابة sudo mkdir -p /var/log/journal). إن كُنّا نرغب برؤية المُدخلات اليوميّة فقط من الإقلاع الحالي نُضيف العَلَم b-: journalctl -b ولمشاهدة رسائل النواة فقط، مثل تلك التي تكون ممثلة عادةً بواسطة dmesg، نستطيع استخدام العَلَم k-: journalctl -k مرةً أخرى، نستطيع تحديد الأمر السّابق ليكون فقط للإقلاع الحالي بإضافة العَلَم b-: journalctl -k -b الاستعلام عن سجلات وحالات الوحدة بينما تُمكّننا الأوامر السّابقة من الوصول إلى الحالة العامّة للنظام، فنستطيع أيضًا الحصول على معلومات حول حالة الوحدات بشكلٍ فردي. يُستخدم الخيار status مع الأمر systemctl للحصول على لمحة عامّة عن الحالة الحاليّة للوحدة، يُظهر لنا هذا الأمر إذا ما كانت الوحدة نشطة، معلومات حول العمليّة process، وآخر المُدخلات اليوميّة: systemctl status nginx.service لمشاهدة كافّة المُدخلات اليوميّة للوحدة التي نسأل عنها نضيف الخيار –u مع اسم الوحدة إلى الأمر journalctl: journalctl -u nginx.service ونستطيع كالعادة تحديد المُدخلات للإقلاع الحالي فقط بإضافة العَلَم b-: journalctl -b -u nginx.service فحص الوحدات وملفات الوحدات نعرف حتى الآن كيفيّة تعديل حالة وحدة ما بواسطة تشغيلها أو إيقافها، ونعلم كيف نشاهد معلومات اليوميّات journal والحالة لأخذ فكرة عمّا يحدث مع العمليّة، ومع ذلك لم نتعلّم كيفيّة فحص inspect جوانب أخرى للوحدات وملفّات الوحدات. يحتوي ملف الوحدة المُعامِلات parameters التي يستخدمها systemd لإدارة وتشغيل الوحدة، ولمشاهدة المحتويات الكاملة لملف الوحدة نكتب: systemctl cat nginx.service ولرؤية شجرة الاعتماديّات dependency tree لوحدة ما (والتي تحاول وحدات systemd تفعيلها عند بدء تشغيل الوحدة) نكتب: systemctl list-dependencies nginx.service يُظهر لنا هذا الأمر الوحدات المعتمدة مع توسيع expand الوحدات الهدف target بشكل تكراري recursively، ولتوسيع كافّة الوحدات المعتمدة بشكل تكراري نُمرِّر العَلَم all--: systemctl list-dependencies --all nginx.service وأخيرًا نستخدم الخيار show لمشاهدة التفاصيل ذات المستوى المُنخفض low-level لإعدادات الوحدة على النّظام: systemctl show nginx.service يُعطينا هذا الأمر قيمة كل مُعامِل تتم إدارته بواسطة systemd. تعديل ملفات الوحدة إن كُنّا نحتاج للقيام بتعديلات على ملف الوحدة فيسمح لنا systemd بالقيام بالتغييرات من خلال الأمر systemctl بنفسه بدون أن نضطر للذهاب إلى موقع الملف الفعلي على القرص. لإضافة مقطع snippet لملف الوحدة، والذي يُمكن استخدامه لإلحاق append أو تجاوز override إعدادات في ملف الوحدة الافتراضي، نستدعي ببساطة الخيار edit على الوحدة: sudo systemctl edit nginx.service وإن كُنّا نرغب بتعديل كامل محتوى ملف الوحدة بدلًا من إنشاء مقطع، نُمرَّر العَلَم --full: sudo systemctl edit --full nginx.service يجب بعد الانتهاء من تعديل ملف الوحدة إعادة تحميل العمليّة systemd نفسها لكي تلتقط تغييراتنا: sudo systemctl daemon-reload استخدام الأهداف targets (مستويات التشغيل Runlevels) ومن الوظائف الأخرى لنظام init نقل الخادوم نفسه بين حالات مختلفة، تُشير أنظمة init التقليديّة لهذا الأمر باسم مستويات التشغيل "runlevels" ممّا يسمح للنظام بأن يكون في مستوى تشغيل runlevel واحد فقط بنفس الوقت. يتم في systemd استخدام الأهداف targets بدلًا من ذلك، والتي هي بشكل أساسي نقاط تزامن يستطيع الخادوم استخدامها لنقل نفسه إلى حالة مُحدّدة، يُمكن أن يتم ربط الخدمة وملفّات الوحدة الأخرى إلى هدف، ويُمكن للأهداف المتعددة أن تكون نشطة في الوقت نفسه. ولرؤية كل الأهداف المتاحة على نظامنا نكتب: systemctl list-unit-files --type=target لمشاهدة الهدف الافتراضي الذي يحاول systemd الوصول إليه عند الإقلاع (والذي بدوره يقوم بتشغيل كافّة ملفّات الوحدة التي تُشكّل شجرة الاعتماديّات لهذا الهدف) نكتب: systemctl get-default نستطيع تغيير الهدف الافتراضي الذي سيتم استخدامه عند الإقلاع باستخدام الخيار set-default: sudo systemctl set-default multi-user.target نكتب ما يلي لكي نرى ما هي الوحدات المرتبطة بالهدف: systemctl list-dependencies multi-user.target يمكننا تعديل حالة النظام للانتقال بين الأهداف عن طريق الخيار isolate، سيقوم هذا بإيقاف تشغيل أيّة وحدات غير مرتبطة بالهدف المحدّد، ويجب أن نكون متأكدين من أنّ الهدف الذي نقوم بعزله isolate لا يوقف تشغيل أيّة خدمات أساسيّة: sudo systemctl isolate multi-user.target إيقاف تشغيل أو إعادة تشغيل الخادوم هنالك بعض الاختصارات المتاحة لبعض الحالات الرئيسيّة التي يستطيع النّظام الانتقال إليها، على سبيل المثال لإيقاف تشغيل خادومنا نكتب: sudo systemctl poweroff إن كُنّا بدلًا من ذلك نريد إعادة تشغيل النظام فبإمكاننا فعل ذلك بكتابة: sudo systemctl reboot نستطيع الإقلاع في وضع الإنقاذ rescue mode بكتابة: sudo systemctl rescue لاحظ أنّ معظم أنظمة التشغيل تقوم بتضمين كنيات aliases تقليديّة لهذه العمليّات بحيث أنّنا نستطيع ببساطة كتابة: sudo poweroff أو sudo reboot بدون systemctl، ومع ذلك ليس من المضمون أن يكون هذا مُعدًّا على كل الأنظمة. الخطوات التالية ينبغي أن نكون الآن قد تعلّمنا أساسيّات إدارة خادوم يستخدم systemd، ومع ذلك هناك المزيد لتعلمّه مع توسّع احتياجاتنا، توجد أدناه روابط دروس تحتوي معلومات أكثر تفصيلًا حول بعض المُكوّنات التي ناقشناها في هذا الدّرس: كيفيّة استخدام Systemctl لإدارة خدمات ووحدات Systemd. كيفيّة استخدام Journalctl لعرض سجلّات Systemd والتعامل معها. فهم وحدات وملفّات وحدات Systemd. نستطيع من خلال تعلّم كيفيّة الاستفادة من قوّة نظام init لدينا أن نتحكّم بحالة أجهزتنا وإدارة خدماتنا وعمليّاتنا بشكل أسهل. ترجمة -وبتصرّف- لـ Systemd Essentials: Working with Services, Units, and the Journal لصاحبه Justin Ellingwood.