شرح systemd في Linux: كيفية إنشاء Service تعمل تلقائيًا عند إقلاع السيرفر باستخدام systemctl (Enable وDisable) – الدليل الكامل 2026

يُعدّ systemd نظام إدارة الخدمات الأساسي في Linux الحديث. إذا كنت تدير خادم Linux أو VPS أو Dedicated Server فمن المؤكد أنك تعاملت مع خدمات مثل NGINX وApache وMariaDB وPHP-FPM وDocker وRedis وغيرها. لكن هل تساءلت يومًا كيف تعمل هذه الخدمات تلقائيًا بعد إعادة تشغيل السيرفر؟ ولماذا تبدأ بعض التطبيقات مباشرة بعد الإقلاع بينما تتوقف تطبيقات أخرى وتحتاج إلى تشغيلها يدويًا؟

الإجابة تكمن في systemd، وهو مدير الخدمات (Service Manager) ونظام التهيئة (Init System) الافتراضي في معظم توزيعات Linux الحديثة مثل Ubuntu وDebian وRocky Linux وAlmaLinux وCentOS Stream.

يعد فهم systemd من أهم المهارات لأي مدير أنظمة أو مسؤول استضافة، لأنه المسؤول عن تشغيل الخدمات وإيقافها وإعادة تشغيلها ومراقبتها، بالإضافة إلى ضمان تشغيل التطبيقات تلقائيًا بعد كل إعادة تشغيل للخادم.

في هذا الدليل ستتعرف على مفهوم systemd، وكيفية إدارة الخدمات باستخدام systemctl، والفرق بين Enabled وActive، وكيفية إنشاء ملف Service Unit احترافي يجعل تطبيقاتك تعمل تلقائيًا عند إقلاع السيرفر.

ما هو systemd؟

systemd هو نظام إدارة الخدمات والإقلاع في Linux، ويعتبر المسؤول عن تشغيل النظام منذ اللحظة الأولى بعد إقلاع النواة (Kernel).

قبل ظهور systemd كانت معظم توزيعات Linux تستخدم أنظمة مثل:

• SysVinit
• Upstart

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

يمكن اعتبار systemd بمثابة “مدير العمليات” داخل السيرفر، فهو المسؤول عن تشغيل الخدمات بالترتيب الصحيح، ومراقبتها، والتأكد من استمرار عملها.

ما هي Service في Linux؟

الخدمة (Service) هي برنامج يعمل في الخلفية دون تدخل مباشر من المستخدم.

وللمزيد من أوامر إدارة Linux، راجع: الدليل الكامل لفحص صحة السيرفر (Server Health Check): أهم أوامر Linux لتشخيص الأعطال ومراقبة الأداء في 2026.

من أشهر الخدمات الموجودة في أي سيرفر:

• NGINX
• Apache
• PHP-FPM
• MariaDB
• MySQL
• Docker
• Redis
• SSH
• Fail2Ban
• Postfix

كل خدمة من هذه الخدمات يتم التحكم بها بواسطة systemd.

ما هو systemctl؟

systemctl هو أداة سطر الأوامر الرسمية للتعامل مع systemd.

وsystemctl هو الأداة الرسمية للتحكّم في systemd؛ للتوثيق الكامل راجع دليل systemctl الرسمي.

من خلاله يمكنك:

• تشغيل الخدمات.
• إيقاف الخدمات.
• إعادة تشغيلها.
• معرفة حالتها.
• تشغيلها تلقائيًا عند الإقلاع.
• تعطيل التشغيل التلقائي.
• إعادة تحميل ملفات الخدمات.

ولهذا يعتبر من أهم أوامر Linux التي يستخدمها مديرو الأنظمة يوميًا.

التحقق من حالة خدمة

لمعرفة حالة أي خدمة استخدم:

systemctl status nginx

أو:

systemctl status php-fpm

إذا ظهرت النتيجة:

Active: active (running)

فهذا يعني أن الخدمة تعمل بصورة طبيعية.

أما إذا ظهرت:

Active: inactive

فهذا يعني أن الخدمة متوقفة.

وإذا ظهرت:

Active: failed

فهذا يعني أن الخدمة حاولت العمل لكنها فشلت.

تشغيل خدمة

لتشغيل خدمة يدويًا:

systemctl start nginx

لن تعمل هذه الخدمة تلقائيًا بعد إعادة تشغيل السيرفر إلا إذا قمت بعملية Enable.

إيقاف خدمة

systemctl stop nginx

يتم إيقاف الخدمة فورًا.

إعادة تشغيل خدمة

systemctl restart nginx

ويستخدم هذا الأمر بعد تعديل ملفات الإعدادات.

إعادة تحميل الإعدادات

في بعض الخدمات مثل NGINX يكفي:

systemctl reload nginx

وبذلك يتم تحميل الإعدادات الجديدة دون إيقاف الخدمة بالكامل.

ما معنى Enable؟

هذا أكثر سؤال يطرحه مستخدمو Linux.

ولحل مشكلة الخدمات التي لا تبدأ بعد الريبوت، راجع: حل مشكلة 502 Bad Gateway بعد إعادة تشغيل السيرفر (NGINX وPHP-FPM وNode.js): الدليل الكامل للتشخيص والإصلاح في 2026.

عند تنفيذ:

systemctl enable nginx

فأنت لا تقوم بتشغيل الخدمة مباشرة.

بل تخبر systemd بأنه في كل مرة يقلع فيها السيرفر يجب تشغيل هذه الخدمة تلقائيًا.

أي أن Enable يعني:

تشغيل الخدمة تلقائيًا بعد كل Restart أو Reboot.

ما معنى Disable؟

إذا نفذت:

systemctl disable nginx

فلن تبدأ الخدمة تلقائيًا بعد إعادة تشغيل السيرفر.

لكن إذا كانت تعمل حاليًا فلن يتم إيقافها.

أي أن Disable يؤثر فقط على الإقلاع القادم.

الفرق بين Active و Enabled

هذه من أكثر النقاط التي تسبب ارتباكًا للمبتدئين.

Active

تعني أن الخدمة تعمل الآن.

مثال:

Active: active (running)

Enabled

تعني أن الخدمة ستعمل تلقائيًا بعد إعادة تشغيل السيرفر.

قد تكون الخدمة:

• Active + Enabled
• Active + Disabled
• Inactive + Enabled
• Inactive + Disabled

لذلك لا تخلط بين الحالتين.

يمكن معرفة حالة Enable بواسطة:

systemctl is-enabled nginx

إذا ظهرت:

enabled

فإن الخدمة ستعمل بعد الإقلاع.

أما:

disabled

فلن تعمل تلقائيًا.

معرفة هل الخدمة تعمل الآن

استخدم:

systemctl is-active nginx

النتائج المحتملة:

active

أو

inactive

أو

failed

عرض جميع الخدمات

لعرض الخدمات العاملة:

systemctl list-units --type=service

أما جميع الخدمات بما فيها المتوقفة:

systemctl list-unit-files

أين توجد ملفات Service؟

غالبًا داخل:

/etc/systemd/system/

أو

/usr/lib/systemd/system/

الملفات الموجودة داخل هذا المجلد تسمى:

Unit Files

وهي التي تخبر systemd كيف يشغل الخدمة.

إنشاء Service خاصة بك

لنفترض أن لديك تطبيق Node.js موجود في:

/opt/myapp/app.js

أنشئ الملف:

/etc/systemd/system/myapp.service

ثم أضف:

[Unit]
Description=My Node Application
After=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/node /opt/myapp/app.js
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

شرح الملف

قسم Unit

Description

اسم الخدمة.

After=network-online.target

يعني لا تبدأ التطبيق إلا بعد جاهزية الشبكة.

قسم Service

WorkingDirectory

مجلد المشروع.

ExecStart

الأمر الذي يشغل التطبيق.

Restart=always

إذا انهار التطبيق يتم تشغيله تلقائيًا.

RestartSec=5

ينتظر خمس ثوانٍ قبل إعادة التشغيل.

قسم Install

WantedBy=multi-user.target

يجعل الخدمة تعمل عند الإقلاع الطبيعي للنظام.

تفعيل الخدمة الجديدة

بعد إنشاء الملف نفذ:

systemctl daemon-reload

لإعادة تحميل ملفات systemd.

ثم:

systemctl enable myapp

ثم:

systemctl start myapp

تحقق من حالتها:

systemctl status myapp

تعديل ملف Service

إذا عدلت الملف:

myapp.service

يجب دائمًا تنفيذ:

systemctl daemon-reload

حتى يقرأ systemd التعديلات الجديدة.

حذف خدمة

أوقفها أولًا:

systemctl stop myapp

ثم:

systemctl disable myapp

ثم احذف الملف:

rm /etc/systemd/system/myapp.service

ثم:

systemctl daemon-reload

متابعة سجلات الخدمة

من أهم الأوامر:

ولفحص صحة الخادم بالكامل، راجع: الدليل الكامل لفحص صحة السيرفر (Server Health Check): أهم أوامر Linux لتشخيص الأعطال ومراقبة الأداء في 2026.

journalctl -u myapp

أو:

journalctl -u nginx

أو:

journalctl -u php-fpm

وهذا يساعدك على معرفة سبب توقف الخدمة أو فشلها.

أفضل الممارسات

• استخدم دائمًا Restart=always للخدمات المهمة.
• لا تشغل التطبيقات يدويًا باستخدام SSH إذا كانت مخصصة للإنتاج.
• اجعل جميع التطبيقات تعمل عبر systemd.
• استخدم journalctl بدلاً من البحث في ملفات Log المتفرقة.
• اختبر الخدمة بعد كل تعديل باستخدام systemctl status.
• تأكد من تنفيذ systemctl enable قبل إعادة تشغيل السيرفر.

أشهر الأخطاء

من الأخطاء الشائعة:

وتوفّر مرام هوست خوادم VPS وDedicated بصلاحيات كاملة لإدارة خدمات systemd بحرية، مع دعم فني عربي يساعدك عند الحاجة.

نسيان تنفيذ:

systemctl daemon-reload

بعد تعديل ملف الخدمة.

أو كتابة مسار خاطئ في:

ExecStart

أو عدم منح صلاحيات التنفيذ للبرنامج.

أو نسيان تنفيذ:

systemctl enable

مما يؤدي إلى توقف التطبيق بعد أول إعادة تشغيل للخادم.

الخلاصة

يُعتبر systemd حجر الأساس في إدارة الخدمات على أنظمة Linux الحديثة، وفهم طريقة عمله يساعدك على إدارة الخوادم بكفاءة أكبر وتقليل الأعطال الناتجة عن توقف التطبيقات بعد إعادة التشغيل. باستخدام أوامر systemctl يمكنك تشغيل الخدمات وإيقافها ومراقبتها، بينما يضمن خيار Enable تشغيلها تلقائيًا عند إقلاع السيرفر.

باختصار، يمنحك systemd عبر systemctl تحكّمًا كاملًا في خدمات خادمك: تشغيلها وإيقافها وتفعيلها عند الإقلاع وإنشاء خدمات خاصة بك. وإتقان systemd خطوة أساسية لكل مدير خوادم Linux.

كما أن إنشاء ملفات Service Unit مخصصة لتطبيقاتك يجعل إدارتها أكثر احترافية واستقرارًا مقارنة بتشغيلها يدويًا. سواء كنت تدير مواقع WordPress أو تطبيقات Laravel أو Node.js أو Python، فإن الاعتماد على systemd يعد من أفضل الممارسات في إدارة خوادم Linux الحديثة.