0Pricing
DevOps Bootcamp · درس

التحكّم في خدمات systemd وكتابة ملفات الوحدات

شغّل الخدمات باستخدام systemctl وأنشئ ملفات الوحدات والمؤقتات المخصّصة للخدمات الخفية المعتمدة على السكربتات

التحكّم في خدمات systemd وكتابة ملفات الوحدات درس مجاني في DevOps Bootcamp على CoddyKit. هذا هو الدرس 2 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في DevOps Bootcamp، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة DevOps Bootcamp 4 دروس في المجموع.

مقدمة إلى systemd وsystemctl

systemd هو نظام init ومدير الخدمات الذي تستخدمه معظم توزيعات Linux الحديثة. وهو مسؤول عن بدء خدمات النظام وإيقافها وإدارتها، إضافةً إلى معالجة تسلسلات الإقلاع وحالة النظام.

الأداة الأساسية للتفاعل مع systemd هي systemctl. ويمكنكم استخدامها من أجل:

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

تُعرّف جميع الخدمات التي يديرها systemd بواسطة ملفات الوحدات، وهي ملفات إعداد تعريفية مخزنة ضمن /etc/systemd/system/ (على مستوى النظام) أو ~/.config/systemd/user/ (لكل مستخدم).

أوامر systemctl الأساسية

هذه أكثر أوامر systemctl استخدامًا لإدارة الخدمات اليومية. يعمل كل أمر على اسم وحدة مثل nginx.service أو nginx ببساطة.

  • systemctl start <unit> — بدء خدمة فورًا
  • systemctl stop <unit> — إيقاف خدمة قيد التشغيل
  • systemctl restart <unit> — إيقاف الخدمة ثم بدء تشغيلها (إعادة تشغيل كاملة)
  • systemctl reload <unit> — إرسال SIGHUP لإعادة تحميل الإعدادات من دون إيقاف الخدمة
  • systemctl enable <unit> — إنشاء روابط رمزية لكي تبدأ الوحدة عند الإقلاع
  • systemctl disable <unit> — إزالة تلك الروابط الرمزية
  • systemctl status <unit> — عرض الحالة ومعرّف العملية PID وآخر سطور السجل
#!/usr/bin/env bash
# Quick reference: inspect and control an nginx service
# (Requires nginx to be installed; run as root or with sudo)

systemctl status nginx
systemctl start nginx
systemctl enable nginx
systemctl reload nginx
systemctl restart nginx
systemctl stop nginx
systemctl disable nginx

التحقق من حالة الخدمة بالتفصيل

يوفّر systemctl status لقطة شاملة عن الوحدة. ويُعد فهم مخرجاته أساسيًا لتشخيص المشكلات بسرعة.

  • Loaded: مسار ملف الوحدة وما إذا كانت مفعّلة عند الإقلاع
  • Active: الحالة الحالية — active (running) أو inactive (dead) أو failed
  • Main PID: معرّف عملية الخدمة الرئيسية
  • CGroup: جميع العمليات الفرعية التابعة للخدمة
  • Log lines: أحدث إدخالات journal الخاصة بهذه الوحدة

يمكنكم أيضًا الاستعلام عن الحالة النشطة فقط باستخدام systemctl is-active، وعن حالة التفعيل باستخدام systemctl is-enabled، وهما مناسبان جدًا للاستخدام في البرامج النصية.

#!/usr/bin/env bash
# Script-friendly service health check
SERVICE="sshd"

if systemctl is-active --quiet "$SERVICE"; then
    echo "$SERVICE is running."
else
    echo "$SERVICE is NOT running. Attempting restart..."
    systemctl restart "$SERVICE"
fi

if systemctl is-enabled --quiet "$SERVICE"; then
    echo "$SERVICE is enabled at boot."
else
    echo "WARNING: $SERVICE is not enabled at boot."
fi

سرد الوحدات وتصفيتها

عند إدارة عدد كبير من الخدمات، تحتاجون إلى طرق فعّالة لسرد الوحدات وتصفيتها. يعرض systemctl list-units جميع الوحدات المحمّلة حاليًا، بينما يعرض list-unit-files جميع ملفات الوحدات المثبّتة وحالة تفعيلها.

خيارات التصفية المفيدة:

  • --type=service — عرض وحدات الخدمة فقط
  • --state=failed — عرض الوحدات الفاشلة فقط
  • --state=active — عرض الوحدات النشطة فقط
  • --all — تضمين الوحدات غير النشطة في القائمة

يتيح دمج عوامل التصفية هذه مع grep إنشاء مسارات فحص قوية في البرامج النصية للصيانة.

#!/usr/bin/env bash
# List all failed services and report them
echo "=== Failed Services ==="
systemctl list-units --type=service --state=failed --no-legend

echo ""
echo "=== Services Enabled at Boot ==="
systemctl list-unit-files --type=service --state=enabled --no-legend | awk '{print $1}'

بنية ملف وحدة خدمة systemd

ملف وحدة الخدمة هو ملف نصي عادي بأسلوب INI، ويتكوّن من أقسام. ويتحكم كل قسم في جانب مختلف من دورة حياة الوحدة.

  • [Unit] — البيانات الوصفية: الوصف وتبعيات الترتيب (After= وRequires= وWants=)
  • [Service] — كيفية بدء العملية وإيقافها: ExecStart وExecStop وRestart وUser وWorkingDirectory
  • [Install] — متى ينبغي تفعيل هذه الوحدة: تعني WantedBy=multi-user.target أنها تُفعّل أثناء إقلاع المستخدمين المتعددين العادي

بعد وضع ملف وحدة أو تحريره ضمن /etc/systemd/system/، يجب تشغيل systemctl daemon-reload لكي يلتقط systemd التغييرات.

كتابة أول ملف لوحدة خدمة

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

توجيهات [Service] الأساسية المستخدمة هنا:

  • Type=simple — يتعامل systemd مع العملية التي يبدأها ExecStart باعتبارها العملية الرئيسية
  • User=www-data — التشغيل باستخدام حساب غير root لأسباب أمنية
  • WorkingDirectory — تعيين دليل العمل للعملية
  • Restart=on-failure — إعادة التشغيل تلقائيًا إذا انتهت العملية برمز غير صفري
  • RestartSec=5 — الانتظار 5 ثوانٍ بين محاولات إعادة التشغيل
#!/usr/bin/env bash
# Create a custom service unit file for a simple HTTP server
# Run as root

cat > /etc/systemd/system/mywebserver.service << 'EOF'
[Unit]
Description=My Custom Python Web Server
After=network.target

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/mysite
ExecStart=/usr/bin/python3 -m http.server 8080
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now mywebserver.service
systemctl status mywebserver.service

أنواع الخدمات ودورة حياة العمليات

يخبر التوجيه Type= ضمن [Service] systemd بكيفية تتبّع اكتمال بدء تشغيل الخدمة. ويُعد اختيار النوع الخاطئ مصدرًا شائعًا لمشكلات الترتيب.

  • Type=simple — النوع الافتراضي؛ يعتبر systemd أن الخدمة بدأت بمجرد تشغيل ExecStart. ولا يلزم إرسال إشارة الجاهزية.
  • Type=forking — تنشئ عملية ExecStart عمليةً فرعية ثم تنتهي؛ ويعمل البرنامج الخدمي الفعلي كعملية فرعية. استخدموا PIDFile= لكي يتمكن systemd من تتبّعه.
  • Type=notify — ترسل العملية sd_notify(READY=1) عند جاهزيتها الفعلية. وهو الأكثر موثوقية للبرامج الخدمية المعقدة.
  • Type=oneshot — يُشغّل العملية مرة واحدة ثم ينتهي؛ وتنتظر الوحدات اللاحقة اكتماله. وهو مثالي لبرامج الإعداد النصية.
  • Type=idle — يشبه simple، لكن يتأخر التنفيذ حتى انتهاء جميع المهام النشطة.
#!/usr/bin/env bash
# Example: oneshot service for a database migration script
# /etc/systemd/system/db-migrate.service

cat > /etc/systemd/system/db-migrate.service << 'EOF'
[Unit]
Description=Run Database Migrations
After=postgresql.service
Requires=postgresql.service

[Service]
Type=oneshot
User=appuser
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/scripts/migrate.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl start db-migrate.service

متغيرات البيئة وتعزيز الأمان

تدعم ملفات وحدات الخدمة عدة توجيهات لتمرير متغيرات البيئة وتطبيق قيود أمنية — وكلاهما مهم في أنظمة الإنتاج.

توجيهات البيئة:

  • Environment="KEY=value" — تعيين متغير واحد ضمن السطر
  • EnvironmentFile=/etc/myapp/env — تحميل المتغيرات من ملف (متغير KEY=value واحد في كل سطر)

توجيهات تعزيز الأمان الشائعة:

  • NoNewPrivileges=true — منع العملية من اكتساب امتيازات إضافية عبر setuid
  • ProtectSystem=strict — تحميل /usr و/boot و/etc للقراءة فقط
  • PrivateTmp=true — منح الخدمة دليل /tmp معزولًا خاصًا بها
  • CapabilityBoundingSet= — إسقاط جميع إمكانات Linux
#!/usr/bin/env bash
# Hardened service unit with environment file

cat > /etc/systemd/system/secureapp.service << 'EOF'
[Unit]
Description=Secure Application Daemon
After=network.target

[Service]
Type=simple
User=secureapp
Group=secureapp
WorkingDirectory=/opt/secureapp
EnvironmentFile=/etc/secureapp/env
ExecStart=/opt/secureapp/bin/server
Restart=on-failure
RestartSec=10

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
CapabilityBoundingSet=
ReadWritePaths=/var/lib/secureapp /var/log/secureapp

[Install]
WantedBy=multi-user.target
EOF

# Create the environment file separately so secrets stay out of the unit file
install -m 600 -o secureapp /dev/null /etc/secureapp/env
echo 'APP_PORT=9000' >> /etc/secureapp/env
echo 'DB_URL=postgresql://localhost/mydb' >> /etc/secureapp/env

systemctl daemon-reload

مقدمة إلى وحدات المؤقت في systemd

مؤقت systemd هو وحدة تُفعّل وحدة أخرى (عادةً .service) وفق جدول زمني. وهو يستبدل مهام cron التقليدية بآلية أكثر تكاملًا وقابلية للتسجيل والتحكم.

تقترن كل وحدة مؤقت (foo.timer) بوحدة خدمة تحمل الاسم الأساسي نفسه (foo.service) وتنفّذ العمل الفعلي. وتقومون بتفعيل المؤقت وبدء تشغيله، وليس الخدمة مباشرة.

أنواع المؤقتات:

  • مؤقتات الوقت الفعلي (التقويم) — تُشغّل المهام في أوقات محددة بحسب ساعة الحائط باستخدام تعبيرات OnCalendar= مثل daily أو weekly أو Mon *-*-* 02:00:00
  • المؤقتات الرتيبة — تُشغّل المهام نسبةً إلى حدث في النظام باستخدام OnBootSec= أو OnActiveSec= أو OnUnitActiveSec=

كتابة ملف وحدة مؤقت

لننشئ زوجًا كاملًا من المؤقت والخدمة لتشغيل برنامج نصي للنسخ الاحتياطي يوميًا عند الساعة 02:00. لاحظوا أن قسم [Timer] يوجد في ملف .timer مستقل، بينما يوجد العمل في ملف .service المقترن به.

توجيهات [Timer] الأساسية:

  • OnCalendar= — تعبير تقويمي للجدول الزمني
  • Persistent=true — إذا كان النظام متوقفًا عند موعد تشغيل المؤقت، فشغّله فورًا عند الإقلاع التالي
  • RandomizedDelaySec= — إضافة قدر عشوائي يصل إلى N ثانية لتجنب اندفاع عدد كبير من المهام عندما تشترك مضيفات كثيرة في الجدول نفسه
  • Unit= — الوحدة المستهدفة صراحةً (اختيارية إذا تطابقت الأسماء)
#!/usr/bin/env bash
# Create a daily backup timer pair
# Run as root

# 1. The service that does the work
cat > /etc/systemd/system/daily-backup.service << 'EOF'
[Unit]
Description=Daily Database Backup
After=network.target postgresql.service

[Service]
Type=oneshot
User=backup
ExecStart=/usr/local/bin/backup-db.sh
StandardOutput=journal
StandardError=journal
EOF

# 2. The timer that schedules it
cat > /etc/systemd/system/daily-backup.timer << 'EOF'
[Unit]
Description=Run Daily Database Backup at 02:00

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target
EOF

systemctl daemon-reload
systemctl enable --now daily-backup.timer

# Verify
systemctl list-timers daily-backup.timer

فحص السجلات واستكشاف أخطاء الوحدات وإصلاحها

يوجّه systemd جميع مخرجات الخدمات إلى السجل journal، الذي يمكنكم الاستعلام عنه باستخدام journalctl. وهذا ي centralise سجلات جميع الوحدات في مخزن واحد قابل للبحث.

أهم خيارات journalctl لاستكشاف أخطاء الخدمات وإصلاحها:

  • -u <unit> — التصفية حسب اسم الوحدة
  • -f — متابعة السجل في الوقت الفعلي (مثل tail -f)
  • -n 50 — عرض آخر 50 سطرًا فقط
  • --since "1 hour ago" — التقييد بحسب الوقت
  • -p err — عرض الأخطاء ذات الأولوية err وما فوقها فقط
  • -b — عرض سجلات الإقلاع الحالي فقط

عندما تفشل وحدة في بدء التشغيل، فإن أول ما ينبغي تشغيله هو journalctl -u <unit> -n 30 --no-pager، ثم systemctl status <unit> للحصول على سياق الأخطاء الحديثة.

#!/usr/bin/env bash
# Troubleshooting helper: dump unit status and recent logs
# Usage: ./service-debug.sh <unit-name>

UNIT="${1:-nginx.service}"

echo "=============================="
echo "STATUS: $UNIT"
echo "=============================="
systemctl status "$UNIT" --no-pager -l

echo ""
echo "=============================="
echo "RECENT LOGS (last 50 lines): $UNIT"
echo "=============================="
journalctl -u "$UNIT" -n 50 --no-pager

echo ""
echo "=============================="
echo "ERRORS ONLY (current boot)"
echo "=============================="
journalctl -u "$UNIT" -b -p err --no-pager

اختبار المعرفة: ملفات وحدات systemd

اختبروا فهمكم لإعداد وحدات الخدمة والمؤقت في systemd.

مراجعة الدرس: التحكم في خدمات systemd وكتابة ملفات الوحدات

استكشفتم في هذا الدرس المفاهيم الأساسية لإدارة خدمات systemd وتأليف ملفات الوحدات على مستوى احترافي. إليكم ملخصًا لما تمت تغطيته:

  • أساسيات systemctl — أوامر البدء والإيقاف وإعادة التشغيل وإعادة التحميل والتفعيل وإلغاء التفعيل وعرض الحالة وis-active وis-enabled لإجراء عمليات تحقق ملائمة للبرامج النصية
  • السرد والتصفية — استخدام list-units وlist-unit-files مع خياري --type و--state لعزل الخدمات الفاشلة أو المفعّلة
  • بنية ملف الوحدة — الأقسام الثلاثة [Unit] و[Service] و[Install] وتوجيهاتها الأساسية
  • أنواع الخدمات — simple وforking وnotify وoneshot ومتى يُستخدم كل منها
  • البيئة والأمان — استخدام EnvironmentFile وNoNewPrivileges وProtectSystem وPrivateTmp لتعزيز أمان البرامج الخدمية
  • وحدات المؤقت — إقران ملفات .timer و.service وتعبيرات OnCalendar وسلوك الاستدراك الخاص بـ Persistent
  • Journalctl — التصفية حسب الوحدة والوقت والإقلاع والأولوية لتشخيص الأعطال بكفاءة

باستخدام هذه المهارات، يمكنكم إدارة أي خدمة نظام، وجدولة المهام المتكررة بصورة موثوقة، وتأليف ملفات وحدات بمستوى الإنتاج للبرامج الخدمية الخاصة بكم.

الأسئلة الشائعة

هل درس «التحكّم في خدمات systemd وكتابة ملفات الوحدات» مجاني؟

نعم — نص درس «التحكّم في خدمات systemd وكتابة ملفات الوحدات» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة DevOps Bootcamp، انتقل إلى CoddyKit PRO. تتضمن دورة DevOps Bootcamp 4 دروس في المجموع.

ماذا ستتعلم في «التحكّم في خدمات systemd وكتابة ملفات الوحدات»؟

شغّل الخدمات باستخدام systemctl وأنشئ ملفات الوحدات والمؤقتات المخصّصة للخدمات الخفية المعتمدة على السكربتات تتمرن على DevOps Bootcamp مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ DevOps Bootcamp؟

لا تُشترط خبرة سابقة. DevOps Bootcamp على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 2 من أصل 4.

كم من الوقت يستغرق درس «التحكّم في خدمات systemd وكتابة ملفات الوحدات»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس DevOps Bootcamp هذا؟

نعم. كل درس في DevOps Bootcamp يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. أتمتة إنشاء المستخدمين والمجموعات
  2. التحكّم في خدمات systemd وكتابة ملفات الوحدات
  3. أتمتة الأقراص وأنظمة الملفات والضمّ
  4. إنشاء سكربتات فحص صحة النظام والتنبيه
← العودة إلى DevOps Bootcamp