المحتوى عن 'systemd'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • التجارة الإلكترونية
  • الإدارة والقيادة
  • مقالات ريادة أعمال عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
    • React
  • HTML
    • HTML5
  • CSS
  • SQL
  • لغة C#‎
  • لغة C++‎
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • Sass
    • إطار عمل Bootstrap
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • ASP.NET
    • ASP.NET Core
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
    • منصة Xamarin
  • سهولة الوصول
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • التسويق بالرسائل النصية القصيرة
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 3 نتائج

  1. يتكوّن نظام التمهيد 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.
  2. شهدت السنوات الأخيرة انتقال توزيعات لينِكس على نحو متزايد من أنظمة 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.
  3. تعرَضنا في دروس سابقة لكيفيّة إدارة الملفات و المستخدمين على RedHat Enterprise Linux؛ نواصل في هذا الدّرس تناول المهامّ الأساسيّة لإدارة خادوم بشرح مبادئ إدارة العمليّات على RedHat Enterprise Linux 7. نبدأ أوّلا بنظرة عامّة على ما يحدُث ابتداءً من اللحظة التي تشغّل فيها زرّ الطاقة على خادوم يعمل على توزيعة RHEL إلى اللحظة التي تظهر فيها شاشة تسجيل الدخول عبر سطر الأوامر. مراحل الإقلاع تنطبق هذه المراحل على توزيعات غنو/لينكس الأخرى مع وجود اختلافات طفيفة. يبدأ اختبار التشغيل الذاتي Power On Self Test بالتحقّق من العتاد Hardware. ينقل اختبار التشغيل الذاتي بعد اكتماله التحكمَ إلى محمِّل الإقلاع الأوّلي First stage boot loader الذي يوجد إما في مقطع الإقلاع على أحد أقراص الجهاز (نظام BIOS)؛ أو في تجزئة Partition منفصلة (نظام UEFI). يمرّر محمّل الإقلاع الأولي التحكّم إلى محمّل الإقلاع الثاني Second stage boot loader الذي يوجد في المجلّد boot/. محمّل الإقلاع الأكثر استخداما هو GRUB (اختصار لـ GRand Unified Boot Loader). يبحث محمّل الإقلاع عن نواة النظام Kernel ونظام ملفات خاصّ يُعرف بـ initramfs يحوي ملفّات وبرامج مهمتها إنجاز الخطوات الضروريّة لتركيب Mount نظام الملفّات الجذر (وهو نظام الملفّات المستخدَم في التجزئة التي يوجد عليها المجلّد root/). تضبط النواة العتاد الموصول بالنظام، ثم بعد تركيب نظام الملفات الجذر تشغّل عمليّة بمعرّف العمليات 1 PID. تجهّز هذه العمليّة بقيّة العمليّات التي من بينها العمليّة المسؤولة عن تسجيل الدخول. تُعرَف العمليّة ذات المعرّف 1 بعمليّة التمهيد Initialization (أو init اختصارا). ملحوظة: يغلب وصف محمّل الإقلاع Boot loader دون تحديد على محمّل الإقلاع الثاني. يمكننا باستخدام الأمر ps عرض لائحة بالعمليّات الحاليّة ذات العمليّة الأم (أي العمليّة التي بدأت تشغيلَ هذه العمليّات) systemd (عمليّة التمهيد في نظام التمهيد SystemD الذي انتقلت إليه أغلب توزيعات لينكس الحديثة): $ ps -o ppid,pid,uname,comm --ppid=1 يمكّننا الخيار o- من تحديد نوعيّة المخرجات التي نرغب في عرضها؛ وهي في هذه الحالة معرّف العمليّة الأمّ ppid، معرّف العمليّة pid، اسم المستخدم الذي شغّل العمليّة uname والأمر comm. يحدّد المعطى الأخير شرطا هو أن يكون معرّف العمليّة الأم يساوي 1 (عمليّة التمهيد). في ما يلي جزء من نتيجةِ تنفيذٍ للأمر: PPID PID USER COMMAND 1 478 root systemd-journal 1 497 root lvmetad 1 513 root systemd-udevd 1 620 root auditd 1 644 root alsactl 1 645 root smartd 1 646 libstor+ lsmd 1 649 root rngd 1 650 root abrtd 1 651 root abrt-watch-log 1 655 root ModemManager 1 656 root systemd-logind 1 657 root irqbalance 1 658 avahi avahi-daemon 1 659 root firewalld 1 662 root accounts-daemon 1 667 root rsyslogd 1 668 root abrt-watch-log 1 673 rtkit rtkit-daemon 1 675 dbus dbus-daemon 1 690 root gssproxy 1 752 root VBoxService 1 760 root ksmtuned 1 762 polkitd polkitd (...) ملحوظة: لجعل النتيجة أسهل للتصفح أعد توجيه الأمر ps أعلاه إلى less؛ ثم استخدم زرّ المسافة على لوحة المفاتيح للانتقال إلى الصفحة الموالية في النتائج، Ctrl+u للانتقال إلى الصفحة السابقة و q للعودة إلى سطر الأوامر: $ ps -o ppid,pid,uname,comm --ppid=1 | less يساعد تخصيص مخرجات الأمر ps في أمور منها على سبيل المثال معرفة العمليّات التي تتسبّب في زيادة استخدام المعالج أو الذاكرة: $ ps aux --sort=+pcpu # ترتيب العمليات تصاعديًّا حسب نسبة استخدام المعالج $ ps aux --sort=-pcpu # ترتيب العمليات تنازليًّا حسب نسبة استخدام المعالج $ ps aux --sort=+pmem # ترتيب العمليات تصاعديًّا حسب نسبة استخدام الذاكرة $ ps aux --sort=-pmem # ترتيب العمليات تنازليًّا حسب نسبة استخدام الذاكرة # ترتيب العمليّات تصاعديًّا حسب استخدام المعالج وتنازليًّا حسب استخدام الذاكرة $ ps aux --sort=+pcpu,-pmem مقدمة إلى SystemD اعتمدت أغلب توزيعات لينكس الحديثة نظام التمهيد SystemD بدلا من أنظمة التمهيد القديمة (مثل SysVinit) نظرا للميزات التي يقدّمها؛ ومن أهمها: إمكانيّة أكبر لتنفيذ العمليّات بالتوازي أثناء التمهيد؛ على عكس SysVinit الأبطأ (ينفّذ SysVinit العمليّات الواحدة تلو الأخرى وينتظر التحقّق من اعتماديّات العمليّات قبل البدء في تشغيل خدمات النظام). يعمل بعد التمهيد على إدارة موارد النظام بطريقة أفضل؛ فالخدمات تشغَّل عند الحاجة إليها فقط من أجل تجنّب استهلاك موارد النظام في عمليّات غير متسخدَمة. التوافق العكسيّ مع سكربتات SysVinit. تدير الأداة systemctl نظام التمهيد SystemD؛ التي تؤدي دورَ الأدوات chkconfig و service و shutdown في نظام التمهيد SysVinit. يبيِّن الجدول التالي التشابه بين عمل systemctl وعمل الأدوات المذكورة. الأمر في SysVinit الأمر في SystemD الوصف service name start systemctl start name تشغيل الخدمة name service name stop systemctl stop name إيقاف الخدمة name service name condrestart systemctl try-restart name إعادة تشغيل الخدمة بشرط أن تكون تعمل حاليا service name restart systemctl restart name إعادة تشغيل الخدمة service name reload systemctl reload name إعادة تحميل إعدادات الخدمة service name status systemctl status name عرض حالة الخدمة service –status-all systemctl عرض حالة جميع الخدمات chkconfig name on systemctl enable name تفعيل تشغيل الخدمة مع إقلاع النظام حسب ما هو محدّد في ملف الوحدة Unit file. تتمثّل عمليّة تفعيل خدمة للتشغيل التلقائي مع الإقلاع (أو تعطيلها) في إضافة وصلات رمزيّة (أو حذفها) إلى المجلّد etc/systemd/system/ (أو حذفها منه). chkconfig name off systemctl disable name تعطيل تشغيل خدمة مع إقلاع النظام. chkconfig --list name systemctl is-enabled name يتحقّق من ما إذا كانت الخدمة مفعَّلة حاليا أم لا chkconfig --list systemctl --type=service تعطيل جميع الخدمات مع ذكر ما إذا كانت الخدمة معطّلة أم مفعَّلة. shutdown -h now systemctl poweroff إيقاف الجهاز shutdown -r now systemctl reboot إعادة تشغيل النظام أضاف SystemD مفهومي الوحدة Unit إلى نظام التمهيد (التي يمكن أن تكون خدمة Service، نقطة تركيب Mount point، جهاز طرفي Device أو مقبس شبكي Network socket) والوجهة Target (الكيفيّة التي يدير بها SystemD عمليّات عدّة مرتبطة في ما بينها). راجع مقال أساسيات Systemd: العمل مع الخدمات، الوحدات Units، واليوميات Journal للمزيد حول نظام التمهيد SystemD. إدارة العمليات تعديل الأولوية في التنفيذ يُستخدَم الأمر renice للتعديل على الأولويّة المعطاة لعمليّة أو عدّة عمليات. تستخدم النواةُ الأولويات لتحديد الكيفيّة التي ستخصّص بها موارد الجهاز للعمليّات. تتراوح الأولويّات Priorities (وتُعرَف أيضا بـ Nices) بين 20- و 19: $ renice priority identifier نحدّد بالمعطى الأول priority الأولويّة التي نريد منحها؛ ثم نحدّد في المعطى الثاني معرّفات عمليّات p-، معرّفات مستخدمين (أو أسماءهم) u- أو معرّفات مجموعات مستخدمين (أو أسماءها) g-. يمكن للمستخدم العادي تغيير أولويّة عمليّاته فقط بشرط ألا يؤدّي التغيير إلى نقص قيمة الأولويّة (قيمة أقلّ تعني أولويّة أكبر). بمعنى أنه يمكن للمستخدم تقليص استخدام عمليّاته للموارد إلا أنه لا يمكنه زيادتها. يحاول الأمر التالي تغيير قيمة أولويّة العمليّة ذات المعرّف 10079 إلى 1-: $ renice -1 -p 10079 إن أردنا تغيير جميع عمليّات المستخدم academy إلى نفس القيمة نطبّق الأمر كالتالي: # renice -1 -u academy إنهاء عملية يُستخدَم الأمر kill لإنهاء العمليّات؛ إلا أن طريقة إنهاء العمليّة تختلف. ينهي الأمر kill العمليّة بإحدى طريقتيْن: إما أن يطلُب من العمليّة إنهاء مهامها (اجمعي أغراضك وانصرفي) أو يتولى هو المهمة بنفسه. إن لم نحدّد طريقة الإنهاء فسيستخدم الأمرُ الطريقةَ الأولى؛ لتحديد الطريقة الثانيّة نستخدم الخيّار 9-. في الواقع، 9 هو معرّف إشارة يُرسلها النظام إلى العمليّة؛ وتتميّز بأنها إشارة لا يمكن للعمليّة تجاهلها (عكسَ الإشارة 15 اللطيفة المستخدَمة في طريقة الإنهاء الأولى). يوجد الأمر pkill الذي يعمل على إنهاء العمليّات بطريقة مشابهة للأمر kill مع فرق أن kill ينهي عمليّة (أو مجموعة عمليّات) بناء على المعرّف؛ في حين أن pkill يمكن أن يستخدم اسم العمليّة أو خاصيّات أخرى. استخدم أمر pgrep إن أردت عرض عمليّات توافق شروطا معينة؛ إن طبّقت أمر pkill على نفس الشروط فسينهي جميع العمليّات التي تنطبق عليها. في المثال التالي نطلُب إنهاء جميع عمليّات المستخدم academy: # pkill -u academy إنهاء العمليّات ليس عمليّة هامشيّة؛ لذا من المستحسن عرض لائحة بالعمليّات التي ينطبق عليها الأمر أعلاه قبل تنفيذه: # pgrep -l -u academy يمكنك الحصول على مزيد من التفاصيل عن الأوامر ps، kill والإشارات Signals في مقال إدارة العمليات (Process) في لينكس باستخدام الطرفية. ترجمة -وبتصرّف- للمقال RHCSA Series: Process Management in RHEL 7: Boot, Shutdown, and Everything in Between – Part 5 لصاحبه Gabriel Cánepa.