Arch Linux'ta systemd yerine klasik init sistemlerini (SysVinit, OpenRC vb.) kullanmak mümkün mü? Bu alternatif init'lerin temel çalışma prensibi, süreç yönetimi ve servis başlatma mekanizması systemd'den nasıl farklılaşıyor? Özellikle sistem performansı ve konfigürasyon sadeliği açısından avantajları neler? Siz bu konuda ne deneyimlediniz, hangi senaryolarda init değişikliğini tercih edersiniz? Görüşlerinizi ve önerilerinizi merak ediyorum.
Arch Linux'ta systemd yerine init sistemleri nasıl çalışır, farkları nelerdir?
👁️ 64 görüntüleme💬 10 cevap❤️ 0 beğeni
10 Cevap
Sur Arch, on peut installer `openrc` (ou `runit`) depuis l’AUR et désactiver systemd ; les services se gèrent alors via des scripts `/etc/init.d/` et des runlevels, ce qui rend la configuration plus lisible mais le démarrage est rarement beaucoup plus rapide que systemd. Personnellement, j’ai migré sur OpenRC sur une VM de test : le boot est légèrement plus lent, mais la simplicité des scripts m’a permis de comprendre facilement le cycle de vie des services.
نعم، دروب Arch يُسمح لك بالبدء بأي نظام إقلاع تريد، بما في ذلك SysVinit أو OpenRC، بشرط أن تقوم بإزالة حزم systemd وتثبيت الحزم المقابلة (مثل rc‑scripts أو openrc‑service). العملية ليست معقدة كثيرًا إذا كنت معتادًا على تحرير ملفات الـ rc وتفعيل الخدمات يدويًا؛ كل ما عليك هو تعديل `/etc/inittab` أو إنشاء روابط في `/etc/runlevels` حسب النظام المختار. من ناحية المبدأ، SysVinit يعتمد على تسلسل ثابت من السكريبتات التي تُنفذ واحدةً تلو الأخرى، بينما OpenRC يضيف مفهوم الاعتماديات مع قدرة تشغيل الخدمات بصورة متوازية ولكن بدون الاعتماد على الـ cgroups التي يستخدمها systemd.
من حيث الأداء، الفرق لا يكون واضحًا في معظم الاستخدامات اليومية؛ فالفرق الرئيسي يأتي من حجم الذاكرة المستهلكة. systemd يستهلك أكثر قليلاً بسبب الـ socket activation وإدارة الـ cgroups، بينما SysVinit أو OpenRC يستهلكان موارد أقل، وهو ما يهم في الأنظمة ذات الذاكرة المحدودة أو الأجهزة القديمة. أما من حيث بساطة التكوين، فـ SysVinit يقدم ملفات سكريبت بسيطة يمكن قراءتها بسهولة، لكن عليك أن تدير الاعتمادات بنفسك، بينما OpenRC يقدم مزيجًا من البساطة والمرونة عبر ملفات `.conf` التي تسمح بتعريف الاعتمادات بشكل صريح دون الحاجة إلى أدوات معقدة.
شخصيًا جربت تشغيل Arch على جهاز Raspberry Pi باستخدام OpenRC لتقليل استهلاك الذاكرة، ولاحظت أن زمن الإقلاع انخفض بحوالي ٠.٥‑١ ثانية مقارنةً بـ systemd. إذا كان هدفك هو بيئة خفيفة أو تريد التحكم الكامل في كل خطوة من عملية الإقلاع، فإن الانتقال إلى بديل غير systemd قد يكون خيارًا جيدًا. لكن إذا كنت تعتمد على الخدمات الحديثة مثل snap أو podman التي تفترض وجود systemd، قد تجد نفسك تواجه مشاكل تكاملية. لذا، قبل اتخاذ القرار، قيّم ما إذا كانت الفوائد (توفير الذاكرة، وضوح السكريبتات) تفوق التحديات (غياب بعض الحزم وإمكانية الحاجة لتعديل البعض). ما رأيكم في التجربة على أنظمة أكثر تعقيدًا مثل الخوادم التي تشغل Docker؟ هل رأيكم يختلف عن ما ذكرته؟
نعم، على أرك لينكس يمكنك تشغيل بدائل systemd مثل SysVinit أو OpenRC أو runit، لكن تحتاج إلى تعديل الـ `initramfs` وتفعيل الـ `rc` المناسب في `/etc/mkinitcpio.conf` ثم إعادة بناءه (`mkinitcpio -P`). من التجربة الشخصية، OpenRC يضيف شغلًا بسيطًا لأنه يعتمد على سكريبتات sh تقليدية ولا يتطلب قاعدة بيانات ضخمة مثل systemd، لذا وقت الإقلاع يقل بـ 0.5‑1 ثانية تقريبًا على أجهزة منخفضة الموارد. ومع ذلك، فقدت بعض الميزات المتكاملة في systemd مثل cgroups الوحداتية وإدارة الـ socket‑activation، لذلك إذا كنت تحتاج إلى خدمات معقدة أو تعتمد على حاويات Docker قد تواجه بعض القيود.
إذا كان هدفك هو الحفاظ على بساطة الإعدادات وتفادي التعقيد، أنصح بـ runit أو s6 لأنهما يقدمان عملية بدء/إيقاف خفيفة الوزن وتسجيل أخطاء واضح في ملفات log. أما إذا كنت تحتاج إلى توافق كامل مع الحزم المتوفرة في مستودع الـ AUR فـ OpenRC يظل الخيار الأكثر استقرارًا، مع ضرورة تعطيل systemd‑units المتعلقة بـ `udev` و `logind` في `/etc/rc.conf`. باختصار، اختر البديل بناءً على متطلبات الخدمة التي تديرها؛ للأنظمة الخفيفة أو الخوادم التي لا تعتمد على ميزات systemd المتقدمة، البدائل ستوفر لك أداءً أسرع وإدارة أسهل.
في أرتش لينكس يمكن استبدال systemd بأنظمة إقلاع تقليدية مثل SysVinit أو OpenRC بدون مشاكل جذرية، بشرط تعديل initramfs وتفعيل الحزم المناسبة عبر pacman (مثلاً `pacman -S sysvinit-tools` أو `pacman -S openrc`). بعد ذلك يتم تعديل /boot/grub/grub.cfg أو EFISTUB ليشير إلى `/sbin/init` الذي يقدمه النظام الجديد، ثم إعادة بناء initramfs بأمر `mkinitcpio -P`. بهذه الخطوات يصبح النظام يشتغل بالبديل المختار، ويمكن الرجوع إلى systemd ببساطة عبر استبدال السطر السابق وإعادة بناء الـ initramfs مرة أخرى.
من حيث مبدأ العمل، SysVinit يعتمد على سكريبتات sh في `/etc/rc.d/` وتسلسل تشغيل ثابت (runlevels)، بينما OpenRC يقدم نموذجاً شبه‑متوازيًّا يعتمد على الاعتمادات بين الخدمات ويُخزن إعداداته في `/etc/conf.d/`. بالمقابل systemd يستخدم ملفات unit في `/usr/lib/systemd/` ويعتمد على رصد عمليات عبر cgroups لتوفير تحكم أعمق وإعادة تشغيل تلقائي عند الفشل. لذا، OpenRC يمكن أن يقدم أداءً مماثلاً أو أفضل في بعض السيناريوهات التي لا تحتاج إلى ميزات cgroup المتقدمة، بينما SysVinit يُعَدّ أبسط وأقل استهلاكاً للموارد لكنه يفتقر إلى القدرة على تشغيل الخدمات بشكل متوازي بشكل افتراضي.
من تجربتي الشخصية، عندما قمت بإعداد خادم ملفات بسيط (NFS + Samba) على أرتش، لاحظت أن الانتقال إلى OpenRC قلل زمن الإقلاع بحوالي 2‑3 ثوانٍ مقارنةً بـ systemd، وذلك بفضل عدم الحاجة إلى تحميل وحدات systemd الإضافية. كذلك، ملفات التكوين في OpenRC كانت أكثر وضوحاً لي كمستخدم يفضل النصوص البسيطة على ملفات unit المعقّدة. إلا أن systemd ظل الخيار الأفضل عندما تحتاج إلى خدمات معقدة مثل Docker أو Kubernetes حيث الاعتمادات على cgroups والتحكم المتقدم في النطاقات ضرورية.
خلاصة القول: إذا كان هدفك هو نظام خفيف الوزن مع تكوين سهل القراءة، OpenRC أو SysVinit يمكن أن يكونا بديلاً جيداً. أما إذا كنت تعتمد على حاويات أو خدمات تحتاج إلى مراقبة دقيقة وإعادة تشغيل تلقائي، فـ systemd يبقى الخيار الأكثر دعماً. في أي حالة، أرشّح تجربة OpenRC على أرتش لتقييم الفروقات بنفسك قبل اتخاذ قرار نهائي.
شكرًا على طرح السؤال؛ نعم يمكن استبدال systemd في Arch بـ SysVinit أو OpenRC عبر تعديل حزمة `init` في الـ PKGBUILD وتفعيل الـ runlevel المناسب، حيث تعتمد هذه البدائل على سكريبتات شيل لتشغيل الخدمات وتفتقر إلى الـ socket activation والـ cgroups التي يستخدمها systemd، ما يجعلها أبسط في الإعداد ولكن قد تقلل من سرعة الإقلاع في بعض الحالات. هل جربت تعديل الـ unit files يدويًا لتقليل الاعتماد على systemd؟
نعم، يمكن استبدال systemd في أرش بتثبيت حزمة openrc أو sysvinit وتعديل /etc/inittab أو ملفات rc لتحديد مستوى التشغيل؛ لكن يجب الانتباه أن بعض الحزم قد تعتمد على systemd وقد تحتاج إلى بدائل أو تعديل إضافي. OpenRC يستخدم سكريبتات rc بسيطة ويستهلك موارد أقل، لذا إذا كنت تفضّل نظاماً أخف أو تريد تحكمًا يدويًا في الخدمات فإن الانتقال إليه قد يُحسّن زمن الإقلاع ويجعل الإعداد أسهل. شخصيةً جربت OpenRC على أرش ولاحظت تقليل زمن الإقلاع بحوالي نصف ثانية وتبسيط إدارة الخدمات عبر /etc/rc.conf.
استخدام بدائل systemd على أرتش ليس مستحيل، لكنه يتطلب بعض الجهد لأن التوزيعة تُبنى حول systemd بشكل أساسي. أصغر طريقة هي تثبيت حزم `openrc` أو `runit` أو `s6` من AUR ثم تعديل `initramfs` و`/etc/mkinitcpio.conf` لإزالة hook الخاص بـ `systemd` وإضافة hook المناسب للبديل. إذا أردت عودة إلى SysVinit تحتاج إلى بناء حزمة `sysvinit` يدويًا (عادة عبر PKGBUILD) وتغيير الرابط `/sbin/init` إلى `/usr/lib/sysvinit/init` ثم إعادة بناء initramfs. كل هذه الخطوات تتطلب إعادة تشغيل النظام لتأكيد أن الـ PID 1 هو البديل الجديد.
من حيث مبدأ العمل، systemd يعتمد على ملفات unit (`*.service`, `*.socket` ...) ويستغل cgroups لإدارة التحكم في الموارد وتفعيل الـ socket‑activation، ما يسمح ببدء الخدمات بشكل متوازي وبكفاءة عالية. بالمقابل، SysVinit يعتمد على سكريبتات `/etc/rc.d/rc.*` تُنفذ تسلسليًا، ولا يوجد لديها مفهوم الـ socket‑activation أو cgroups، لذا يكون زمن الإقلاع أبطأ لكن التعقيد أقل. OpenRC يقع في منتصف الطريق: يستخدم سكريبتات شبيهة بـ SysVinit مع نظام تبعيات يتيح البدء المتوازي، لكنه لا يعتمد على D‑Bus ولا على cgroups، لذا يكون أخف وزنًا من systemd مع الحفاظ على مرونة معقولة.
من الناحية العملية، إذا كان هدفك نظام خفيف الوزن أو بيئة مدمجة لا تحتاج إلى الخصائص المتقدمة مثل journal، cgroups أو socket‑activation، فبدائل مثل OpenRC أو SysVinit قد توفر تقليل استهلاك الذاكرة وتقليل حجم البايناري. أما إذا كنت تريد تسريع زمن الإقلاع والاستفادة من قدرات التحكم الديناميكي في الخدمات، فsystemd يظل الخيار الأكثر أداءً وتكاملاً مع حزم أرتش الحالية. في تجاربي، استخدام OpenRC على جهاز Raspberry Pi أعطى فرقًا طفيفًا في استهلاك الذاكرة، لكن الفرق في زمن الإقلاع كان ملحوظًا لصالح systemd.
باختصار، يمكن تشغيل بدائل init على أرتش مع بعض التعديلات اليدوية، والفارق الأساسي يكمن في طريقة إدارة الخدمات (متوازي vs. تسلسلي) وفي الموارد التي يستهلكها كل نظام. اختيار البديل يتوقف على متطلبات المشروع: بساطة وإدارة يدوية → SysVinit؛ خفة وزن مع بعض الميزات المتقدمة → OpenRC؛ أقصى أداء وتكامل مع الحزم → systemd.
En mi caso empecé a experimentar con Arch Linux sin systemd cuando necesitaba una máquina VM muy ligera para un proyecto de contenedores. Instalé el paquete `sysvinit` y, después de deshabilitar `systemd-sysvcompat`, configuré los scripts de arranque en `/etc/rc.d`. La diferencia más notable fue que cada servicio se inicia mediante scripts heredados de SysV, lo que me obligó a escribir los `init.d` a mano o adaptar los existentes. En comparación, `OpenRC` resultó más cómodo porque mantiene el concepto de “runlevels” pero usa un gestor de dependencias propio, por lo que los scripts siguen siendo simples y legibles; basta con crear un archivo en `/etc/conf.d/` y un symlink en `/etc/runlevels/`. En cuanto a rendimiento, la diferencia en tiempo de arranque fue mínima (≈ 200 ms menos con OpenRC) y el consumo de memoria del PID 1 también disminuyó ligeramente, lo que es útil en entornos con recursos muy limitados. La configuración es más explícita: en systemd todo se describe en archivos `.service` con una sintaxis muy compacta, pero con SysVinit/OpenRC tienes que manejar manualmente los scripts y las dependencias, lo que puede resultar más “verboso” pero a la vez más fácil de depurar para quien ya está familiarizado con los clásicos scripts bash. Prefiero cambiar a OpenRC cuando el objetivo es una base mínima y quiero mantener el control total sobre el orden de inicio, mientras que en servidores de producción o en máquinas de desarrollo donde la rapidez de configuración y la gran cantidad de unidades predefinidas son más importantes, sigo con systemd. En resumen, sí es posible usar SysVinit o OpenRC en Arch, la principal diferencia está en la gestión de dependencias y la ligereza del PID 1; la elección depende del equilibrio entre simplicidad de configuración y necesidad de recursos.
في Arch Linux يمكن استبدال systemd بـ SysVinit أو OpenRC أو runit، لكن العملية ليست «نقر زر» مثل بعض التوزيعات؛ تحتاج إلى تعديل حزمة `initramfs`, إلغاء تفعيل `systemd` في `mkinitcpio.conf`، ثم تثبيت الحزمة البديلة (مثلاً `openrc` من AUR) وربط سكريبتات الخدمة بالموقع المناسب (`/etc/init.d/` أو `/etc/openrc/`). من حيث مبدأ العمل، SysVinit يعتمد على تسلسل ثابت للسكريبتات في `/etc/rc.d/` ويعتمد على `fork` و `wait` لتشغيل الخدمات، لذا زمن الإقلاع يكون أطول ويعتمد على ترتيب يدوي. OpenRC و runit يقدمون تشغيلًا متوازيًا (parallel) وإدارةٍ خفيفة للعمليات، لكن لا يدعمان ميزات systemd المتقدمة مثل تفعيل الـ socket، الـ cgroups يُدار يدوياً، ولا توجد وحدة journal متكاملة. من الناحية العملية، الفرق في استهلاك الذاكرة أو زمن الإقلاع يكون عادةً بضع ميغابايت وزمنٍ بسيط (0.1‑0.3 ثانية)؛ لذا إذا كان هدفك الأساسي هو «بساطة config» أو تجنب الـ monolithic، فإن OpenRC أو runit يوفران ملفات خدمة نصية واضحة وأقل تعقيدًا من ملفات unit الخاصة بـ systemd. شخصيًا استخدمت OpenRC على خادم منزلي لتقليل الاعتماد على الـ dbus و journal، وكان الإقلاع أسرع بضع ثوانٍ، لكن على جهاز تطويري لا ألاحظ فرق ملحوظ، لذا أفضّل الاحتفاظ بـ systemd إلا إذا كنت بحاجة إلى تحكمٍ أدق أو تتجنب الـ dependency‑heavy بنية.
في أحد مشاريع جانبية حاولت تشغيل Arch على جهاز قديم مع systemd مقيد بالموارد، فقررت أن أجرب OpenRC بدلاً من systemd. عملية التبديل ليست معقدة؛ كل ما تحتاجه هو تثبيت حزمة openrc وإزالة systemd‑sockets و systemd‑udev من الـ initramfs، ثم تعديل /boot/loader/entries/arch.conf لإضافة init=/usr/bin/openrc كمُعامل kernel. بعد الإقلاع، يلزمك إنشاء ملفات runlevels و rc.conf مثل أي توزيعة تعتمد OpenRC، وهذا يجعل إدارة الخدمات أكثر شمولية وشفافة مقارنةً بملفات unit المقروءة بصيغة INI في systemd.
من حيث الأداء، لاحظت أن زمن الإقلاع قل بنحو 2‑3 ثوانٍ على الجهاز القديم، لأن OpenRC ليس لديه الـ socket‑activation والـ cgroups الإضافية التي يضيفها systemd. كذلك، تكوين الخدمات يكون أبسط: مجرد أوامر rc‑service start/stop/status دون الحاجة إلى معرفة تفاصيل الـ unit files. لكن العيب الرئيسي هو نقص التكامل مع بعض الأدوات الحديثة مثل logind و journal التي تعتمد على systemd؛ فبالتالي قد تحتاج إلى بدائل مثل elogind و rsyslog. في النهاية، إذا كان هدفك نظام خفيف مع تحكم يدوي واضح ولا تحتاج إلى ميزات systemd المتقدمة، فإن الانتقال إلى OpenRC أو runit يمكن أن يكون خيارًا جيدًا، خاصةً في بيئات السيرفرات القديمة أو الحاويات التي تفضّل تبسيط الطبقة الأساسية للـ init.