Systemd

systemd یک سیستم init است که توسط برخی توزیع‌های لینوکس برای خودآماده‌سازی فضای کاربر و همچنین مدیریت همه پروسه‌ها بعد از خود است. این سیستم جایگزین یونیکس سیستم‌وی یا سیستم BSD init است. حرف d در systemd از کلمه daemon در سیستم‌های یونیکس گرفته شده. این نرم‌افزار تحت پروانه عمومی همگانی گنو انتشار یافته. یکی از هدف‌های systemd، متحد کردن تنظیمات پایه‌ای لینوکس و رفتار سرویس‌ها در میان همه توزیع‌ها است.

systemd

نویسنده(های) اصلی	Lennart Poettering, Kay Sievers
توسعه‌دهنده(ها)	Lennart Poettering, Kay Sievers and others
انتشار اولیه	۳۰ مارس ۲۰۱۰ (۲۰۱۰-03-۳۰)
انتشار پایدار	۲۲۱ / ۱۹ ژوئن ۲۰۱۵ (۲۰۱۵-19}})
مخزن	github.com/systemd/systemd
نوشته‌شده با	سی
سیستم‌عامل	لینوکس
نوع	اینیت =
مجوز	در ابتدا پروانه عمومی همگانی گنو، در حال حاضر گنو ال‌جی‌پی‌ال ۲٫۱+
وبگاه	freedesktop.org/…/systemd/

از سال ۲۰۱۵، بسیاری توزیع‌های لینوکس سیستم‌دی را به عنوان سیستم init پیش‌فرض قرار دادند. افزایش استفاده از سیستم‌دی، با مشاجرات منتقدان بحث‌برانگیز شد. منتقدان معتقد بودند که این نرم‌افزار، فلسفه یونیکس را با افزایش پیچیدگی و فشار بر سازگاری بسیاری نرم‌افزارها همچون گنوم۳ نقض کرده‌اند.

طراحی

معماری سیستم‌دی به گونه‌ای که در تایزن به کار رفته‌است. بسیاری از بخش‌ها، شامل telephony, bootmode, dlog و tizen service، مربوط به تایزن هستند و بخش‌های سیستم‌دی نیستند.

سلسله‌مراتب متحد cgroups منحصراً توسط سیستم‌دی با استفاده از systemd-nspawn قابل دسترسی خواهد بود.

لینارت پوترینگ و کای سیورز، مهندسان نرم‌افزاری که برای ردهت کار می‌کردند، و پدیدآورندگان سیستم‌دی، به دنبال بهتر کردن کارایی init در حالت‌های مختلف بودند. آن‌ها می‌خواستند چارچوب نرم‌افزاری را به‌گونه‌ای به‌سازی کنند که پیش‌نیازها در آن ارائه شود تا بتوان پردازش‌های بیشتری را به‌طور هم‌زمان به صورت موازی در زمان بوت اجرا کرد، و همچنین سربار محاسباتی پوسته (شل) کاهش یابد.

پوترینگ توسعه سیستم‌دی را این‌گونه توضیح می‌دهد: «هرگز تمام نشده، هیچ‌گاه کامل نشده، اما سیر پیشرفت تکنولوژی را می‌پیماید». در می ۲۰۱۴، پوترینگ همچنین سیستم‌دی را به عنوان سعی در متحدسازی «تفاوت بیهوده میان توزیع‌ها»، با ارائه این قابلیت‌های عمومی تعریف کرد:

• یک سیستم و مدیر سرویس (مدیریت سیستم، با استفاده از اعمال تنظیمات متعدد، و سرویس‌های آن)
• یک پلتفرم نرم‌افزاری (ارائه به عنوان یک پایه برای توسعه نرم‌افزار دیگر)
• چسبی میان برنامه‌ها و کرنل (ارائه رابط‌های متعدد که عمل‌کردهای ارائه‌شده توسط کرنل را به نمایش می‌گذارد)
  

سیستم‌دی تنها نام دایمن init نیست، بلکه اشاره به تمام نرم‌افزاری که پیرامون آن متصل شده نیز می‌کند که علاوه بر دایمن systemd init، شامل دایمنهای journald, logind و networkd و بسیاری بخش‌های سطح پایین دیگری نیز می‌شود. در ژانویه ۲۰۱۳، پوترینگ سیستم‌دی را به عنوان نه‌فقط یک برنامه، بلکه به جای آن، یک مجموعه نرم‌افزاری بزرگ شامل ۶۹ باینری منحصربه‌فرد توضیح داد. به عنوان یک مجموعه نرم‌افزاری پیچیده، سیستم‌دی جایگزین فرایند راه‌اندازی لینوکس و سطوح اجرایی می‌شود که با دایمن متداول init و با استفاده از اسکریپت‌های شل کنترل می‌شد. سیستم‌دی همچنین بسیاری از سرویس‌هایی را که در سیستم‌های لینوکس معمول هستند با استفاده از اداره ورود کاربران، کنسول سیستم، device hotplugging (نگاه کنید به udev)، اجرای زمان‌بندی‌شده (جایگزین cron)، گزارش‌گیری، نام‌گذاری هاست‌ها و locale در خود ادغام کرده‌است.

همچون دایمن init، سیستم‌دی نیز یک دایمن است که دایمنهای دیگر را مدیریت می‌کند، که خود سیستم‌دی نیز یکی از آن‌هاست. سیستم‌دی اولین دایمنی است که در طول بوت (راه‌اندازی) آغاز می‌شود و آخرین دایمنی است که در طول خاموش شدن از کار می‌افتد. دایمن سیستم‌دی به عنوان ریشه درخت پردازش در فضای کاربر سرویس می‌دهد. پروسه اول (pid 1) نقش خاصی در سیستم‌های یونیکس دارد، چراکه هنگامی که یک پروسه دایمن بسته می‌شود، سیگنال SIGCHILD دریافت می‌کند؛ بنابراین، اولین پروسه مخصوصاً بهترین جایگاه را برای مانیتور کردن دایمن‌ها دارد.

سیستم‌دی، بخش‌های راه‌اندازی را به صورت موازی اجرا می‌کند، که سریع‌تر از راه‌اندازی سنتی است. برای ارتباطات داخلی پردازش‌ها، سیستم‌دی Unix domain socket و D-Bus را برای اجرای دایمن‌ها فراهم آورده‌است. خود حالت سیستم‌دی نیز می‌تواند به صورت یک snapshot (تصویر) برای فراخوان بعدی محفوظ باشد.

فایل‌های Unit

سیستم‌دی دستورالعمل‌های راه‌اندازی برای هریک از دایمن‌ها را در یک فایل تنظیمات (که فایل Unit خوانده می‌شود) ذخیره می‌کند که از یک زبان declarative استفاده می‌کند، و جایگزین اسکریپت‌های شل که برای راه‌اندازی هر کدام از دایمن‌ها استفاده می‌شد می‌شود. انواع فایل‌های یونیت، شامل service, socket, device, mount, automount, swap, target, path و timer (که می‌تواند مانند یک زمان‌بند شبهcron استفاده شود), snapshot, slice و scope.

اجزای هسته و کتاب‌خانه‌ها

با توجه به رویه ادغامی آن، سیستم‌دی همچنین جایگزینی برای ابزار دایمن‌ها، شامل اسکریپت‌های شل راه‌اندازی، pm-utils, inetd, acpid, syslog, watchdog, cron و atd ارائه می‌دهد. اجزای هسته سیستم‌دی، شامل این‌ها می‌شود:

• systemd یک مدیر سیستم و سرویس برای سیستم‌عامل‌ها لینوکس است.
• systemctl می‌تواند برای کنترل وضعیت سیستم سیستم‌دی و مدیر سرویس به کار رود.
• systemd-analyze می‌تواند برای مشخص کردن مختصات کارایی سیستم در هنگام راه‌اندازی و بازیابی حالت‌های دیگر و ردیابی اطلاعات از سیستم و مدیر سرویس‌ها به کار رود.
  

سیستم‌دی پردازش‌ها را به جای استفاده از شناسه‌های آن‌ها با استفاده از زیرسیستم‌های cgroups کرنل لینوکس ردیابی می‌کند؛ بنابراین، دایمن‌ها نمی‌توانند حتی با استفاده از double-forking از زیر دست سیستم‌دی «فرار کنند». سیستم‌دی نه تنها از cgroups استفاده می‌کند، بلکه همچنین آن‌ها را با systemd-nspawn و machinectl افزایش می‌دهد. از نسخه ۲۰۵، سیستم‌دی همچنین ControlGroupInterface را که یک API برای cgroups کرنل لینوکس است ارائه می‌دهد. cgroups کرنل لینوکس برای پشتیبانی kernfs سازگار شده‌اند، و در حال ویرایش برای پشتیبانی از یک سلسله‌مراتب متحد هستند.

قطعات جانبی

در کنار هدف اولیه آن، برای ارائه جایگزین سیستم init، مجموعه سیستم‌دی عملکردهای اضافه‌ای هم ارائه می‌دهد. این مجموعه شامل موارد زیر می‌شود:

consoled

systemd-consold یک دایمن کنسول کاربری ارائه می‌دهد، تا بتواند جایگزین ترمینال مجازی کرنل لینوکس با اجزای توانای بیشتری در فضای کاربری. نسخه پیش‌نمایش آن در اکتبر ۲۰۱۴، بخشی از سیستم‌دی نسخه ۲۱۷ منتشر شد.

journald

systemd-journald یک دایمن است که مسئول گزارش اتفاقات است که از فایل‌های باینری فقط-اضافه‌ای به عنوان فایل‌های لاگ خود استفاده می‌کند. مدیر سیستم می‌تواند برای گزارش اتفاقات سیستم از systemd-journald, syslog-ng یا rsyslog استفاده کند. مشکلات فرمت باینری موجب بالا گرفتن مشاجرات در مورد سیستم‌دی شد.

logind

systemd-logind یک دایمن است که ورود کاربران و نشست آن‌ها را در روش‌های مختلفی مدیریت می‌کند. می‌تواند یک مدیر ورود پیچیده باشد که چندنشست‌های پیشرفته‌تری را ارائه می‌کند؛ و جایگزین ConsoleKit، که دیگر پشتیبانی ندارد شود. برای مدیران نمایش X11 تغییر وضعیت به استفاده از logind یک عملیات انتقال کوچک نیاز است. logind از نسخه ۳۰ به سیستم‌دی اضافه شده‌است.

networkd

networkd یک دایمن است که تنظیمات رابط‌های شبکه را در دست دارد. در نسخه ۲۰۹، هنگامی که برای اولین بار اضافه شد، پشتیبانی آن به آدرس‌های استاتیک و پشتیبانی پایه‌ای برای تنظیمات پل‌زنی محدود بود. در ژوئیه ۲۰۱۴ سیستم‌دی نسخه ۲۱۵، با اضافه کردن قابلیت‌هایی همچون DHCP Server برای هاست‌های آی‌پی ورژن۴ و پشتیبانی از VXLAN منتشر شد.

timedated

systemd-timedated یک دایمن است که می‌تواند برای کنترل تنظیمات مربوط به زمان به کار رود، همچون زمان سیستم، منطقه زمانی سیستم، یا انتخاب میان UTC و منطقه زمانی محلی ساعت سیستم. این دایمن از طریق D-Bus قابل دسترسی است. این ویژگی از نسخه ۳۰ اضافه شد.

udevd

udev یک مدیر دستگاه‌های جانبی برای کرنل لینوکس است، که شاخه dev/ و همه کارهای فضای کاربر را با اضافه/کم کردن دستگاه‌ها همچون بارگیری firmware مدیریت می‌کند. در آوریل ۲۰۱۲، شاخه کد منبع udev به شاخه کد سیستم‌دی ادغام شد.

libudev

این کتاب‌خانه استاندارد برای به‌کارگیری udev است، که به ابزارهای دیگر اجازه پرس‌وجو از منابع udev را می‌دهد.

ظاهر گرافیکی

تصویر رابط کاربری سیستم‌دی، یک ظاهر برپایه GTK+ برای سیستم‌دی.

تعداد اندکی ظاهر گرافیکی در دسترس هستند، شامل:

systemd-ui

که همچنین systemadm نیز گفته می‌شود، و یک ظاهر گرافیکی ساده بر پایه GTK+ برای سیستم‌دی است. یک رابط کاربری ساده برای مدیریت سرویس‌ها و یک مأمور گرافیکی برای درخواست پسورد از کاربر. از ۲۰۱۴ برنامه systemdadm توسعه و نگهداری اندکی دریافت کرده‌است، چراکه تمرکز به ابزارهای خط-فرمان همچون systemctl و systemd-analyze منتقل شده.

systemd-kcm

یک ظاهر گرافیکی سیستم‌دی برای دسکتاپ کی‌دی‌ای پلاسما ۵ ارائه می‌دهد. این در پنجره تنظیمات سیستم ادغام می‌شود و اجازه نظارت و کنترل بخش‌های سیستم‌دی و نشست‌های ورود، و همچنین ویرایش گرافیکی فایل‌های تنظیمات را می‌دهد.

تصویب و پذیرش

در حالی که بیشتر توزیع‌ها سیستم‌دی را به صورت پیش‌فرض بارگیری می‌کنند، برخی، به سیستم‌های init دیگری اجازه استفاده می‌دهند. در این حالت، تغییر حالت سیستم‌های init با نصب بسته‌های مناسب امکان‌پذیر است. شاخه فورکی از دبین پیشنهاد شده تا از سیستم‌دی اجتناب کند.

تصویب سیستم‌دی برای توزیع‌های بزرگ لینوکس

توزیع لینوکس	تاریخ اضافه شدن به مخزن نرم‌افزاری	فعال به‌طور پیش‌فرض؟	قابلیت اجرا بدون آن؟	تاریخ انتشار با حالت پیش‌فرض
آرچ لینوکس	۰۲۰۱۲−۰۱ ژانویه ۲۰۱۲	آری	بله، اما پشتیبانی نمی‌شود	۰۲۰۱۲−۱۰ اکتبر ۲۰۱۲
کور او-اس	۰۲۰۱۳−۰۷ ژوئیه ۲۰۱۳	آری	؟	۰۲۰۱۳−۱۰ اکتبر ۲۰۱۳ (v94.0٫0)
دبیان	۰۲۰۱۲−۰۴ آوریل ۲۰۱۲	آری	آری	۰۲۰۱۵−۰۴ آوریل ۲۰۱۵ (v8)
فدورا	۰۲۰۱۰−۱۱ نوامبر ۲۰۱۰ (v14)	آری	نه	۰۲۰۱۱−۰۵ مه ۲۰۱۱ (v15)
جنتو لینوکس	۰۲۰۱۱−۰۷ ژوئیه ۲۰۱۱	نه	آری	—
مجیا	۰۲۰۱۱−۰۱ ژانویه ۲۰۱۱ (v1.0)	آری	؟	۰۲۰۱۲−۰۵ مه ۲۰۱۲ (v2.0)
اوپن سوزه	۰۲۰۱۱−۰۳ مارس ۲۰۱۱ (v11.4)	آری	؟	۰۲۰۱۲−۱۱ نوامبر ۲۰۱۲ (v12.2)
ردهت	۰۲۰۱۴−۰۶ ژوئن ۲۰۱۴ (v7.0)	آری	نه	۰۲۰۱۴−۰۶ ژوئن ۲۰۱۴ (v7.0)
اسلکور	ن/م (در مخزن نیست)	—	آری	—
سوزه لینوکس انترپرایز سرور	۰۲۰۱۴−۱۰ اکتبر ۲۰۱۴ (v12)	آری	نه	۰۲۰۱۴−۱۰ اکتبر ۲۰۱۴ (v12)
اوبونتو	۰۲۰۱۳−۰۴ آوریل ۲۰۱۳ (v13.04)	آری	؟	۰۲۰۱۵−۰۴ آوریل ۲۰۱۵ (v15.04)

یکپارچگی با نرم‌افزار دیگر

با توجه به علاقه به ارتقای قابلیت همکاری میان سیستم‌دی و دسکتاپ گنوم، نویسنده مشترک سیستم‌دی، لینارت پوترینگ از پروژه گنوم درخواست کرد که سیستم‌دی را به عنوان پیش‌نیاز خارجی برای گنوم ۳٫۲ قرار دهد.

در نوامبر ۲۰۱۲، پروژه گنوم به این نتیجه رسید که عمل‌کردهای پایه‌ای گنوم نباید به سیستم‌دی وابسته باشد. هرچند، گنوم ۳٫۸ یک انتخاب برای زمان کامپایل میان logind و ConsoleKit API قرار داد؛ که اولی در آن زمان فقط توسط سیستم‌دی ارائه می‌شد. اوبونتو یک باینری جدا برای logind ارائه کرد، اما سیستم‌دی یک پیش‌نیاز برای گنوم برای بیشتر توزیع‌های لینوکس است. به‌خصوص، از آنجایی که ConsoleKit دیگر نگهداری فعال ندارد و جریان توزیع‌ها پیشنهاد می‌دهد که از systemd-logind به جای آن استفاده شود. توسعه‌دهندگان لینوکس جنتو همچنین تلاش دارند این تغییرات را در OpenRC سازگار کنند، اما پیاده‌سازی آن شامل تعداد زیادی باگ شد، که موجب شد این توزیع سیستم‌دی را به عنوان پیش‌نیاز گنوم قرار دهد.

گنوم سازگاری بیشتری با logind پیدا کرد. از نسخه ۳٫۱۳٫۲ به بعد، logind پیش‌نیازی برای نشست‌های ویلند شد. تصمیماتی هم برای جایگزینی gنهme-session با سیستم‌دی گرفته شد، اما سیستم‌دی نمی‌بایست به عنوان PID ۱ اجرا شود تا gنهme-session همچنان در سیستم‌های غیر لینوکس در دسترس باشد. از آنجایی که سیستم‌دی فقط لینوکس را پشتیبانی می‌کند و با خاطر استفاده زیاد آن از APIهای کرنل لینوکس نمی‌تواند به سادگی به سیستم‌عامل‌های دیگر منتقل شود، لازم است که APIهای سازگار با سیستم‌عامل‌های دیگر همچون اوپن‌بی‌اس‌دی ارائه شوند.

در مصاحبه ZDNet در سپتامبر ۲۰۱۴، توسعه‌دهنده برجسته کرنل لینوکس، تئودور تسو، نظر خود را راجع به نزاع دربارهٔ فلسفه طراحی متمرکز سیستم‌دی ارائه کرد، بیش از نگرانی‌های تکنیکی، پیش‌بینی کرد رشد عمومی خطرناکی به سمت یکسان‌سازی اکوسیستم لینوکس حاصل شود، و بخشی از اجتماع متن‌باز به حاشیه رانده و فضای کمی برای پروژه‌های جایگزین به وجود آید. وی در این پروژه، تشابهاتی با نگرشی که در پروژه گنوم به سمت تنظیمات غیر استاندارد پیدا کرد. در رسانه‌های اجتماعی، تسو همچنین مقایسه‌هایی میان نگرش دو توسعه‌دهنده کلیدی سیستم‌دی با توسعه‌دهنده‌های گنوم انجام داد.

تاریخچه و مجادله

طراحی سیستم‌دی با مخالفت اجتماع نرم‌افزار آزاد ساخته شد. منتقدان گفتند که سیستم‌دی شدیداً پیچیده است و پیشرفت ویژگی‌های آن به کندی پیش خواهد رفت و معماری آن در تضاد با اصول طراحی سیستم‌عامل‌های شبه‌یونیکس است. همچنین این نگرانی وجود خواهد داشت که سیستمی ساخته شود که وابستگی‌های قفل شده به وجود آورد، به گونه‌ای که به نگهداران توزیع‌ها انتخاب‌های کمی داده می‌شود اما سیستم‌دی را سازگارتر می‌سازد تا نرم‌افزار فضای کاربر بیشتر به بخش‌های سیستم‌دی وابسته شود.

یادداشت‌ها

در می ۲۰۱۱، فدورا اولین توزیعی شد که سیستم‌دی را به صورت پیش‌فرض فعال نمود.

در یک مصاحبه در ۲۰۱۲، رهبر اسلکور، پتریک ولکردینگ، توضیح داد که معتقد است طراحی آن با فلسفه یونیکس که ابزارها را با توابع تعریف‌شده کم، متفاوت است. از اوت ۲۰۱۴، اسلکور از سیستم‌دی استفاده نمی‌کند و آن را پشتیبانی نمی‌کند، اما ولکردینگ احتمال تغییر حالت به آن را رد نکرد.

در بین اکتبر ۲۰۱۳ و فوریه ۲۰۱۴، و تبادل نظر طولانی در کمیته تکنیکی دبین در فهرست ایمیل دبین، در بحث دربارهٔ انتخاب سیستم init پیش‌فرض برای دبین ۸ «جسی» و تصمیم‌گیری نهایی دربارهٔ وضعیت سیستم‌دی انجام گرفت. این تبادل نظر به‌طور وسیعی عمومی شد و در همان آغاز این تبادل نظر در فهرست ایمیل دبین ادامه پیدا کرد.

در ژانویه ۲۰۱۳، لینارت پوترینگ، تصمیم گرفت که نگرانی‌های راجع به سیستم‌دی را در یک پست وبلاگ به نام «بزرگترین راز» قرار داد. پس از پایان مناظرات دربارهٔ سیستم‌دی در اکتبر ۲۰۱۴، پوترینگ اعلام کرد که «اجتماع متن‌باز» پر از احمق است و من احتمالاً یکی از مورد علاقه‌ترین هدف‌های آن‌ها هستم. پوترینگ سپس لینوس توروالدز و دیگر توسعه‌دهندگان کرنل را به خاطر وضعیت اجتماع مورد ملامت قرار داد.

در فوریه ۲۰۱۴، پس از تصمیم دبین، مارک شاتلورث در وبلاگ خود اعلام کرد که اوبونتو نیز در اجرای سیستم‌دی آن‌ها را دنبال خواهد کرد.

در آوریل ۲۰۱۴ یک کمپین برای تحریم سیستم‌دی در یک وبسایت شکل گرفت و دلایل مختلف را در برابر انتخاب سیستم‌دی ارائه کرد.

در یک مقاله در اوت ۲۰۱۴ در نشریه InfoWorld، پاول ونزیا دربارهٔ مجادله سیستم‌دی نوشت، و این مجادله را به تضاد سیستم‌دی با فلسفه یونیکس و «غرور عظیمی که شدیداً معتقد هستند خطا نمی‌کنند» نسبت داد. این مقاله همچنین معماری سیستم‌دی را مشابه svchost.exe، یک بخش بحرانی مایکروسافت ویندوز با دامنه عملیاتی وسیع دانست.

در نوامبر ۲۰۱۴، مراقبان دبین و اعضای کمیته تکنیکی، جوی هس، روس البری، یان جکسن، و مراقب بسته سیستم‌دی، تولف فوگ هین، از منصب خود استعفا دادند. هر چهار نفر تصمیم خود را در فهرست ایمیل اعلام عمومی‌کردند و در بلاگ شخصیشان با نگرانی و قرار گرفتن در معرض استرس شدید مربوط به ادغام سیستم‌دی با دبین و اجتماع متن‌باز، اعلام کردند که تعمیر و نگهداری منظم، کاری غیرممکن می‌شود.

در دسامبر ۲۰۱۴، یک شاخه از دبین، به نام دو-وان، توسط گروهی که خود را «مدیران کهنه دبین» نامیدند معرفی شد. قصد آن‌ها ارائه یک نوع دبین بدون نصب پیش‌فرض سیستم‌دی است.

در اوت ۲۰۱۵، سیستم‌دی یک شل ورود به نام machinectl shell ارائه داد.

در اکتبر ۲۰۱۵، یک مقاله به نام «کمبود ساختاری و معنایی در معماری سیستم‌دی برای مدیریت سرویس در دنیای واقعی» منتشر شد، که سیستم‌دی را در بسیاری زمینه‌ها مورد انتقاد قرار داد، از جمله طراحی آن به عنوان یک سیستم شیئی با لایه‌های بسیار از تغییرمسیر، که آن را مستعد ایجاد خطاهای مربوط به ترتیب می‌کند، یک مدل با پیش‌بینی اجرای دشوار، ترتیب راه‌اندازی غیرقطعی، حالت غیرقطعی در فایل تنظیمات و نارسا بودن کلی آن در ارائه یک چکیده از انواع یونیت‌ها.