ایجاد سرویس های سفارشی در systemd
systemd
در سیستم عامل گنو/لینوکس، کرنل به تنهایی همه ی فرآیند های سیستم را انجام نمیدهد و بخشی از کارها را اعم از مدیریت سرویس ها، دیمون ها و سایر برنامه ها را به پروسه دیگری به اسم init میدهد.
در دنیای لینوکس سیستم های مختلفی برای init وجود دارد که مهمترین و رایج ترین آنها امروزه systemd است. systemd اولین دیمونی است که در هنگام بوت شدن شروع می شود و آخرین دیمونی است که در حین خاموش شدن پایان می یابد. systemd به عنوان ریشه درخت فرآیند های فضای کاربر عمل می کند. اولین فرآیند (PID 1) نقش ویژه ای در سیستم های یونیکسی دارد.
systemd برای مدیریت بهتر فرآیند های سیستم، هر منبعی را که سیستم میداند چگونه با آن کار کرده و آن را مدیریت کند (اعم از سرویس ها، دیوایس ها و...) به عنوان یک یونیت(unit) تعریف میکند.
هر یونیت یک اسم، یک نوع و یک فایل کانفیگ دارد.
۱۲ نوع یونیت وجود دارد:
automount, device, mount, path, scope, service, slice, snapshot, socket, swap, target, timer
در این ویکی میخواهم نحوه ایجاد و مدیریت سرویس های سفارشی در سیستم دی را شرح دهم.
هر سرویس شامل یک فایل کانفیگ است که عموما در دایرکتوری etc/systemd/system/ به فرمت service_name>.service> قرار دارد.
به طور مثال برای سرویس sshd فایل مقابل را داریم: etc/systemd/system/sshd.service/
ساختار فایل یونیت
هر فایل کانفیگ یک سرویس از سه بخش [Unit] , [Service] , [Install] تشکیل شده. در هرکدام از این بخش ها تنظیمات مورد نظر و مربوط به آن بخش قرار دارد.
[Unit]
شامل آپشن های عمومی است که به نوع یونیت بستگی ندارد. این آپشن ها مواردی مثل وابستگی های یک یونیت، ترتیب بارگذاری آن، توضیح مختصری از یونیت و... میباشد.
برخی از مهم ترین آپشن های این بخش:
Description -> شامل توضیحات مختصری از یونیت
Documentation -> شامل URL هایی که به آن یونیت مربوط میشود
Requires -> یونیت های وابسته به این سرویس را مشخص میکند که هنگام فعال شدن این سرویس فعال میشوند و در صورتی که یونیت مشخص شده در این بخش فعال نشود سرویس هم فعال نخواهد شد
Conflicts -> مخالف رفتار Requires عمل میکند و یونیت هایی را مشخص میکنند که با سرویس تضاد دارند
[Service]
