راهنمای جامع مدیریت Processها در لینوکس

این مقاله برای افرادی در نظر گرفته شده است که با سیستم عامل لینوکس آشنایی دارند و می خواهند مدیریت پروسه ها در سرورهای لینوکسی خودشان را بر عهده بگیرند. اگر از افراد مبتدی هستید بهتر است ابتدا از مباحث پایه لینوکس مانند کار با ترمینال شروع کنید.

Process چیست؟

همانطور که می دانید برنامه ها در تمام سیستم عامل ها در قالب پروسه یا process اجرا می شوند. در واقع اجرای یک برنامه در سیستم عامل یک پروسه یا process نامیده می شود. زمانی که سیستم عامل لینوکس در حال بالا آمدن روی سیستم شما است init system اتفاقی می افتد. یعنی ابتدا کرنل لینوکس بارگذاری شده و سپس کامپوننت هایی بارگذاری می شوند که سیستم به آن ها نیاز خواهد داشت.

در هر حال دو نوع پروسه در لینوکس وجود دارد:

Background processes (پروسه های پس زمینه)
Foreground processes (پروسه های پیش زمینه)

هر پروسه ای که در ترمینال شروع می شود یک پروسه پیش زمینه است چرا که روبروی شما است و شما می توانید با آن تعامل داشته باشید. از طرف دیگر اگر این پروسه را به پس زمینه انتقال بدهید آنگاه یک پروسه پس زمینه خواهیم داشت. به طور مثال دستور زیر یک پروسه پیش زمینه را شروع می کند:

sudo apt-get upgrade -y

ما می توانیم با اضافه کردن & به انتهای یک دستور آن پروسه را به پس زمینه انتقال بدهیم:

sudo apt-get upgrade -y &

حالا اگر بخواهیم پروسه های پس زمینه را مشاهده کنیم. با انجام این کار چنین نتیجه ای را می گیرید:

[1]+  Stopped                 sudo apt-get upgrade -y

یعنی یک پروسه داشته ایم که حالا متوقف شده است (stopped). چرا؟ به دلیل اینکه دستور apt-get upgrade معمولا سریعا تمام می شود.

نکته: هر پروسه یک id خاص دارد که به آن PID می گوییم. لینوکس از این id برای شناسایی یک پروسه خاص استفاده می کند. در طول این مقاله PID را زیاد خواهید دید.

برنامه های مختلف برای مدیریت process ها

در لینوکس نرم افزار های مختلفی برای مدیریت process ها وجود دارد. هر distribution از سیستم عامل لینوکس (مثلا Ubuntu و Arch و Fedora و SUSE و ...) از یک یا چند عدد از این نرم افزار ها استفاده می کند اما یادگیری تمام آن ها فقط هدر دادن وقت شما است. بهتر است نحوه کار با یکی از این برنامه ها را یاد بگیرید و همیشه از همان برنامه استفاده کنید چرا که در نهایت همه آن ها یک کار را انجام می دهند.

من در این مقاله در رابطه با دو مورد از مشهور ترین برنامه های مدیریت پروسه در لینوکس صحبت خواهم کرد: ps و systemd. برنامه ps بسیار قدیمی است اما هنوز هم به راحتی کار شما را انجام می دهد. در عین حال systemd جدیدتر است و قابلیت های بیشتری دارد بنابراین ما به هر دو نگاهی می اندازیم.

آشنایی با PS

با اجرای دستور ps aux می توانید تمام پروسه های در حال اجرا در سیستم خود را مشاهده کنید. البته من پیشنهاد می دهم نتیجه را به برنامه less بدهید تا خوانا تر باشد:

ps aux | less

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

ps -u amir

amir نام حساب کاربری من روی سیستم شخصی خودم است، طبیعتا شما باید نام حساب کاربری خودتان را در این بخش قرار بدهید. با اجرای این دستور لیستی از پروسه های در حال اجرا توسط کاربری به نام amir را مشاهده خواهید کرد:

    PID TTY          TIME CMD

   1657 ?        00:00:00 systemd

   1658 ?        00:00:00 (sd-pam)

   1664 ?        00:00:00 pipewire

   1665 ?        00:00:00 pipewire-media-

// بقیه پروسه ها

همانطور که می بینید در ستون اول PID یا شناسه آن پروسه خاص را داریم.

فلگ f- باعث می شود لیست پروسه های نمایش داده شده به صورت کامل و با جزئیات مفصل باشد:

UID          PID    PPID  C STIME TTY          TIME CMD

amir        1657       1  0 09:13 ?        00:00:00 /lib/systemd/systemd --user

amir        1658    1657  0 09:13 ?        00:00:00 (sd-pam)

amir        1664    1657  0 09:13 ?        00:00:00 /usr/bin/pipewire

// بقیه پروسه ها

ساختار درختی

البته اگر به جای f- از f (بدون -) استفاده کنید، این لیست کامل به همراه یک ساختار درختی نمایش داده می شود:

   PID TTY      STAT      1940 ?        Sl     0:04  |   \_ ibus-daemon --panel disable --xim

   1944 ?        Sl     0:00  |   |   \_ /usr/libexec/ibus-memconf

   1945 ?        Sl     0:02  |   |   \_ /usr/libexec/ibus-extension-gtk3

   2156 ?        Sl     0:01  |   |   \_ /usr/libexec/ibus-engine-simple

   2239 ?        Sl     0:00  |   \_ gjs /usr/share/gnome-shell/extensions/ding@rastersoft.com/ding.js

// بقیه پروسه ها

همانطور که می بینید ارتباط پروسه ها به یکدیگر به صورت شاخه شاخه نمایش داده شده است.

در صورتی که می خواهید نتایج نمایش داده شده ظاهر زیباتری داشته باشند باید دستور pstree را اجرا کنید. این دستور پروسه ها را به صورت یک درخت واقعی نمایش می دهد:

systemd─┬─ModemManager───2*[{ModemManager}]

        ├─NetworkManager───2*[{NetworkManager}]

        ├─accounts-daemon───2*[{accounts-daemon}]

        ├─acpid

        ├─gdm3─┬─gdm-session-wor─┬─gdm-x-session─┬─Xorg───14*[{Xorg}]

        │      │                 │               ├─gnome-session-b───2*[{gnome-session-b}]

        │      │                 │               └─2*[{gdm-x-session}]

        │      │                 └─2*[{gdm-session-wor}]

        │      └─2*[{gdm3}]

        ├─gnome-keyring-d───3*[{gnome-keyring-d}]

        ├─irqbalance───{irqbalance}

// بقیه پروسه ها

فرض کنید با استفاده از دستورات قبل PID یکی از پروسه های مورد نظرتان را به دست آورده اید و حالا می خواهید آن را در این درخت پیدا کنید تا متوجه رابطه آن با دیگر پروسه ها شوید. برای این کار باید از ساختار دستوری زیر استفاده کنید:

pstree -H [PID]

به طور مثال اگر PID یک پروسه 20596 باشد می گوییم:

pstree -H 20596

با انجام این کار پروسه مورد نظر در درخت با فونت توپُر (bold) نوشته خواهد شد.

همچنین اگر می خواهید ساختار درختی را فقط برای یک پروسه خاص ببینید باید از فلگ s- استفاده نمایید:

pstree -s [PID]

طبیعتا اگر آن پروسه خاص وابستگی های دیگری به پروسه های دیگر نداشته باشد، ساختار درختی به صورت یک خط صاف خواهد بود:

systemd───systemd───chrome───chrome───chrome───chrome───16*[{chrome}]

همچنین می توانید ساختار درختی را به پروسه های یک حساب کاربری خاص محدود کنید:

pstree [userName]

طبیعتا به جای [userName] باید نام حساب کاربری مورد نظرتان را قرار بدهید.

پیدا کردن PDI و متوقف کردن پروسه ها

اگر به دنبال پیدا کردن PID یک پروسه خاص هستید، استفاده از ساختار های درختی کمکی به شما نمی کند چرا که ساختار های درختی بیشتر برای درک رابطه بین پروسه ها هستند. در صورتی که هدف شما پیدا کردن یک PID خاص است بهتر است از دستور pgrep یا به طور کلی grep استفاده کنید. ساختار استفاده از این دستور به شکل زیر است:

pgrep [option] [pattern]

در بخش options از گزینه های موجود برای این دستور استفاده می کنیم و در بخش pattern یک الگوی خاص برای پیدا کردن یک پروسه خاص را می نویسیم. به طور مثال اگر من به دنبال پروسه گوگل کروم باشم می توانم بدین شکل عمل کنم:

pgrep -u amir chrome

با اجرای این دستور لیستی از PDI هایی که نام پروسه chrome را داشته باشند نمایش داده می شوند. البته من شخصا ترجیح می دهم نام پروسه نیز در کنار PID آن باشد نه اینکه فقط شناسه های تنها نمایش داده شوند. برای انجام این کار باید فلگ l- را نیز به دستور بالا پاس بدهیم:

pgrep -u amir chrome -l

با انجام این کار نتیجه ای شبیه به نتیجه زیر را دریافت می کنید:

4618 chrome

4720 chrome-gnome-sh

19885 chrome

20568 chrome

20583 chrome

// دیگر پروسه ها

همانطور که می بینید مرورگر کروم چندین پروسه جداگانه را اجرا می کند. این مسئله برای بسیاری از برنامه ها طبیعی است بنابراین نباید باعث تعجب شما بشود. ما می توانیم با اضافه کردن فلگ c تعداد این پروسه ها را بشماریم:

pgrep -u amir chrome -l -c

با اجرای این دستور عدد ۲۲ را دریافت می کنم که یعنی گوگل کروم ۲۲ پروسه را اجرا کرده است.

حالا فرض برنامه معروف LibreOffice را باز کرده اید و می خواهید PID آن را پیدا کنید. اولین کار این است که دستور زیر را اجرا می کنیم:

pgrep -u amir libre -l

با اجرای این دستور هیچ نتیجه ای نمی گیریم. چرا؟ به دلیل اینکه برخی از برنامه ها نام پروسه متفاوتی از نام برنامه انتخاب می کنند بنابراین دیگر دستور pgrep جواب نمی دهد. در این حالت با استفاده از ps aux و grep کردن آن عمل می کنیم:

ps aux | grep libre

با اجرای این دستور نتایج زیر را می گیریم:

amir       19733  0.0  0.1 102340  4936 ?        Sl   09:22   0:00 /opt/libreoffice7.1/program/oosplash --writer file:///media/amir/Development/Roxo%20Academy/Systemd%20in%20Linux.odt

amir       19749  4.2  7.4 1632660 293724 ?      Sl   09:22   5:20 /opt/libreoffice7.1/program/soffice.bin --writer file:///media/amir/Development/Roxo%20Academy/Systemd%20in%20Linux.odt --splash-pipe=5

amir       23394  0.0  0.0  22472   852 pts/2    S+   11:28   0:00 grep --color=auto libre

حالا می توانیم این پروسه را ببینیم. عدد اول در هر خط (اعداد 19733 و 19749 و 23394) همان PID های برنامه هستند.

کشتن یک Process

احتمالا می پرسید چرا باید به دنبال PID یک پروسه باشیم؟ شناسایی یک پروسه کاربرد های زیادی دارد. مثلا رایج ترین کاربرد این است که آن پروسه را متوقف کنید. برای این کار از دستور killall یا kill استفاده می کنیم:

sudo killall [process name]

به طور مثال برای متوقف کردن کروم می گوییم:

sudo killall chrome

این دستور تمام پروسه های کروم را متوقف می کند. مشکل این دستور این است که به صورت خودکار تمام پروسه های یک برنامه را متوقف می کند اما شاید ما به دنبال پروسه های خاصی باشیم. در این حالت باید به جای killall از kill استفاده کنیم و طبیعتا اینجاست که شناسایی PID موثر خواهد بود:

sudo kill [PID]

به طور مثال:

sudo kill 23503

هر دو دستور kill و killall در حالت عادی از خود برنامه می خواهند که خودش را متوقف کند اما در برخی اوقات که سیستم هنگ کرده است برنامه به شما پاسخی نمی دهد. در این حالت بهتر است از فلگ 9- استفاده کنید:

sudo killall -9 chrome

sudo kill -9 23503

این کار برنامه را به طور کامل و مستقیما توسط سیستم متوقف می کند.

دستور ps می تواند مکمل خوبی برای systemd باشد. در بخش بعدی درباره systemd صحبت می کنیم.

آشنایی با Systemd

systemd نرم افزاری برای سیستم های لینوکس است که در سال های اخیر به عنوان استاندارد مدیریت پروسه ها در نظر گرفته می شود و بیشتر distribution های مختلف لینوکس از آن استفاده می کنند. با توجه به شهرت بزرگ systemd، امروزه یادگیری آن یکی از ضروریات یادگیری لینوکس شده است تا بتوانید برنامه های خود را مدیریت کنید.

نکته: در صورتی که در در هنگام اجرای دستورات توضیح داده شده در این مقاله با bash: systemctl is not installed روبرو شدید باید بدانید که systemd برایتان نصب نشده است. شما می توانید بر اساس توضیحات distribution لینوکسی که از آن استفاده می کنید، systemd را نصب کنید (مثال: sudo apt install systemd).

هدف عملیات ها در systemd چیزی به نام unit است که در فارسی به معنی «واحد» می باشد. این unit ها دارای پسوند هستند و معمولا دستوراتی که مدیریت کننده هستند از این پسوند استفاده می کنند (مثلا عملیات های مدیریتی پسوند service را دارند) اما systemd به اندازه کافی هوشمند است تا نیازی به ذکر این پسوند ها نداشته باشد.

همچنین باید بدانید که تمام دستورات systemd با عبارت systemctl شروع می شوند. تمام دستوراتی که با systemctl شروع می شوند متعلق به systemd هستند و طبیعتا نیاز به دسترسی سطح ادمین (sudo) دارند.

شروع یا متوقف کردن سرویس ها

برای شروع کردن یک سرویس باید از دستور start استفاده کنیم:

sudo systemctl start application.service

همانطور که قبلا هم گفتم systemd می داند که باید به دنبال فایل های service.* بگردد بنابراین نیازی به ذکر پسوند service نیست:

sudo systemctl start application

در دستور بالا باید به جای application نام برنامه مورد نظرتان را قرار بدهید. مثلا اگر بخواهیم وب سرور آپاچی را در سرور لینوکسی خودمان استارت کنیم، می گوییم:

sudo systemctl start apache2

در عین حال من در این مقاله از پسوند service استفاده می کنم تا دستورات صریح و مشخص باشند.

همچنین برای متوقف کردن یک سرویس از دستور stop استفاده می کنیم:

sudo systemctl stop application.service

در صورتی که می خواهید سرویس مورد نظر را ریستارت کنید، دستور restart را در اختیار دارید:

sudo systemctl restart application.service

این دستور باعث ریستارت شدن کامل سرویس مورد نظر می شود اما برخی از برنامه ها (مثلا سرویس ssh در لینوکس) به شما اجازه می دهند یک فایل پیکربندی را بدون ریستارت کردن ثبت کنید. در این حالت باید از دستور reload استفاده نمایید:

sudo systemctl reload application.service

اگر نمی دانید برنامه شما قابلیت reload را دارد می توانید از دستور reload-or-restart استفاده کنید.

sudo systemctl reload-or-restart application.service

غعال یا غیر فعال کردن سرویس ها

فعال یا غیر فعال بودن یک سرویس به معنی این است که آیا در هنگام بالا آمدن سیستم عامل، آن سرویس باید به صورت خودکار اجرا شود یا خیر (چیزی شبیه به startup در ویندوز). مثلا وب سرور آپاچی باید پس از هر ریستارت اجرا شود بنابراین باید آن را فعال کنید. برای فعال کردن سرویس ها از دستور enable استفاده می کنیم:

sudo systemctl enable application.service

زمانی که یک سرویس را نصب کرده اید فایلی به همان نام در مسیر lib/systemd/system یا etc/systemd/system ایجاد می شود. اجرای دستور بالا باعث می شود یک symbolic link از آن فایل در مسیر etc/systemd/system/some_target.target.wants نیز ایجاد شود. سرویس های درون این مسیر به صورت خودکار در هنگام روشن شدن سیستم اجرا می شوند.

خلاف این دستور نیز disable است که به سرویس خاصی اجازه اجرا شدن به صورت خودکار را نمی دهد:

sudo systemctl disable application.service

بررسی وضعیت یک سرویس

برای بررسی وضعیت یک سرویس باید از دستور status استفاده کنید:

sudo systemctl status application.service

به طور مثال اگر بخواهیم وضعیت پایگاه داده redis را در سرور خود چک کنیم، می گوییم:

sudo systemctl status redis.service

نتیجه اجرای این دستور به شکل زیر خواهد بود:

redis-server.service - Advanced key-value store

     Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)

     Active: active (running) since Thu 2021-07-08 23:19:57 +0430; 17min ago

       Docs: http://redis.io/documentation,

             man:redis-server(1)

   Main PID: 942 (redis-server)

     Status: "Ready to accept connections"

      Tasks: 5 (limit: 4553)

     Memory: 5.1M

     CGroup: /system.slice/redis-server.service

             └─942 /usr/bin/redis-server 127.0.0.1:6379




Jul 08 23:19:51 AmirPC systemd[1]: Starting Advanced key-value store...

Jul 08 23:19:57 AmirPC systemd[1]: Started Advanced key-value store.

هماطور که می بینید وضعیت (بخش Active) روی فعال است. عبارت active و running که به عنوان مقدار این فیلد نوشته شده اند به معنی در حال اجرا بودن این پروسه در پس زمینه هستند. البته کد هایی برای بررسی جداگانه وضعیت های مختلف یک سرویس نیز وجود دارند. به طور مثال برای در حال اجرا بودن یک سرویس از دستور is-active استفاده می کنیم:

sudo systemctl is-active application.service

با اجرای این دستور اگر سرویس شما در حال اجرا باشد عبارت active و در غیر این صورت عبارت inactive را دریافت می کنید. همچنین برای بررسی وضعیت فعال بودن (اجرای خودکار با هر بار بالا آمدن سیستم عامل) دستور is-enabled را در اختیار داریم:

sudo systemctl is-enabled application.service

اگر سرویس شما فعال باشد کلمه enabled و در غیر این صورت disabled را دریافت می کنید.

در نهایت برای بررسی بروز خطا در یک سرویس از دستور is-failed استفاده می کنیم:

sudo systemctl is-failed application.service

اگر سرویس شما بدون خطا در حال اجرا باشد نتیجه active و اگر خطایی رخ داده باشد نتیجه failed را می گیرید. البته اگر خودتان یک سرویس را متوقف کرده باشید نتیجه به شکل unknown یا inactive نمایش داده خواهد شد.

لیست کردن تمام unit ها

اگر به خاطر داشته باشید در ابتدای بخش systemd برایتان توضیح دادم که هدف عملیات ها در systemd چیزی به نام unit است که در فارسی به معنی «واحد» می باشد. به زبان ساده تر unit ها منابعی هستند که برای systemd شناخته شده اند و systemd می داند چطور آن ها را مدیریت کند.

برای مشاهده تمام unit های در حال اجرا در سیستم خود می توانید از دستور زیر استفاده کنید:

sudo systemctl list-units

نتیجه اجرای این دستور چیزی به شکل نتیجه زیر خواهد بود:

UNIT                                      LOAD   ACTIVE SUB     DESCRIPTION

atd.service                               loaded active running ATD daemon

avahi-daemon.service                      loaded active running Avahi mDNS/DNS-SD Stack

dbus.service                              loaded active running D-Bus System Message Bus

dcron.service                             loaded active running Periodic Command Scheduler

dkms.service                              loaded active exited  Dynamic Kernel Modules System

getty@tty1.service                        loaded active running Getty on tty1

// دیگر واحد ها

در نتیجه بالا ۵ ستون مختلف دیده می شود:

UNIT: نام unit یا واحد مورد نظر است.
LOAD: اگر عبارت loaded در این ستون باشد یعنی تنظیمات پیکربندی آن واحد خاص توسط systemd بارگذاری شده است. این دسته از تنظیمات پیکربندی در مموری سیستم (RAM) قرار دارند.
ACTIVE: این بخش مشخص می کند که آیا واحد مورد نظر فعال است یا خیر. هیچ اطلاعات اضافه دیگری در این بخش مشخص نمی شود.
SUB: این بخش اطلاعات جزئی تری در رابطه با واحد را در اختیار ما می گذارد. به طور مثال running به معنی «در حال اجرا» بودن و exited به معنی «خارج شده» بودن است. حالت های مختلف دیگر نیز در این بخش وجود دارد.
DESCRIPTION: یک توضیح متنی کوچک از وظیفه هر واحد در این بخش نمایش داده می شود.

دستور بالا فقط واحد هایی را نمایش می دهد که در حال حاضر فعال باشند اما اگر می خواهید تمام واحد های موجود در سیستم را مشاهده کنید (حتی موارد غیر فعال) باید فلگ all- را به آن پاس بدهید:

sudo systemctl list-units --all

همچنین اگر می خواهید فقط واحد هایی با وضعیت خاصی را دریافت کنید می توانید از فلگ state-- استفاده کنید:

sudo systemctl list-units --all --state=inactive

و در نهایت برای دریافت واحد هایی با نوع مشخص از فلگ type-- استفاده خواهیم کرد:

sudo systemctl list-units --type=service

در نهایت باید گفت که اضافه کردن فلگ all-- باعث نمایش تمام واحد هایی می شود که از نظر systemd لازم بوده اند بنابراین خوانده شده اند اما فایل های unit دیگری نیز وجود خواهند داشت. اگر می خواهید تمام فایل های unit را مشاهده کنید باید از دستور زیر استفاده نمایید:

systemctl list-unit-files

با اجرای این دستور نتیجه ای شبیه به نتیجه زیر را دریافت خواهید کرد:

UNIT FILE                                  STATE  

proc-sys-fs-binfmt_misc.automount          static 

dev-hugepages.mount                        static 

dev-mqueue.mount                           static 

proc-fs-nfsd.mount                         static 

proc-sys-fs-binfmt_misc.mount              static 

sys-fs-fuse-connections.mount              static 

sys-kernel-config.mount                    static 

sys-kernel-debug.mount                     static 

tmp.mount                                  static 

var-lib-nfs-rpc_pipefs.mount               static 

org.cups.cupsd.path                        enabled

// بقیه فایل های واحد

همانطور که می بینید دو ستون وجود دارد: UNIT FILE (نام فایل واحد) و STATE (وضعیت واحد). وضعیت هر واحد می تواند enabled (فعال) و disabled (غیر فعال) و static (استاتیک) و masked (ماسک شده) باشد. استاتیک یعنی فایل واحد دارای بخش install نیست. این بخش به systemd می گوید که چطور آن واحد خاص را فعال کند. چنین واحد هایی معمولا یا فقط یک کار را یک بار انجام می دهند و یا اینکه به عنوان وابستگی دیگر واحد ها استفاده می شوند. درباره masked نیز بعدا صحبت خواهیم کرد.

بررسی محتوای فایل های Unit

اگر دوست دارید محتوای فایل های unit را مشاهده کنید، می توانید از دستور cat استفاده نمایید. مثلا من می خواهم محتویات فایل واحد redis را مشاهده کنم بنابراین می گویم:

sudo systemctl cat redis.service

با اجرای این کد چنین نتیجه ای را دریافت می کنید:

[Unit]

Description=Advanced key-value store

After=network.target

Documentation=http://redis.io/documentation, man:redis-server(1)




[Service]

Type=notify

ExecStart=/usr/bin/redis-server /etc/redis/redis.conf --supervised systemd --daemonize no

PIDFile=/run/redis/redis-server.pid

TimeoutStopSec=0

Restart=always

User=redis

Group=redis

RuntimeDirectory=redis

RuntimeDirectoryMode=2755

//بقیه کد ها

همچنین اگر می خواهید لیستی از وابستگی های یک واحد را ببینید از دستور list-dependencies استفاده می کنیم. من در کد زیر این کار را برای redis انجام داده ام:

sudo systemctl list-dependencies redis.service

نتیجه معمولا یک ساختار درختی به شکل زیر است:

redis.service

├─-.mount
├─system.slice
└─sysinit.target
├─apparmor.service
├─dev-hugepages.mount
├─dev-mqueue.mount
├─keyboard-setup.service
├─kmod-static-nodes.service
├─plymouth-read-write.service
├─plymouth-start.service
├─proc-sys-fs-binfmt_misc.automount

// دیگر وابستگی ها

تمام واحد های بالا واحد هایی هستند که برای اجرا شدن redis مورد نیاز هستند و باید با ترتیب خاص خودشان اجرا شوند.

در مرحله بعدی می توانیم با استفاده از دستور show خصوصیات تنظیم شده برای یک واحد را نمایش بدهیم. مثال:

sudo systemctl show redis.service

با اجرای این دستور خصوصیات تنظیم شده برای واحد redis به ما نمایش داده می شود:

Type=notify

Restart=always

PIDFile=/run/redis/redis-server.pid

NotifyAccess=main

RestartUSec=100ms

TimeoutStartUSec=1min 30s

TimeoutStopUSec=infinity

TimeoutAbortUSec=infinity

TimeoutStartFailureMode=terminate

TimeoutStopFailureMode=terminate

RuntimeMaxUSec=infinity

WatchdogUSec=0

// دیگر خصوصیات

اما اگر بخواهید فقط یکی از این خصوصیات را دریافت کنید باید از فلگ p- استفاده نمایید:

sudo systemctl show redis.service -p Conflicts

با اجرای این دستور فقط مقدار مورد نظر برای این خصوصیت را دریافت می کند:

Conflicts=shutdown.target

اگر بخواهیم یک واحد خاص را به عنوان «غیر قابل شروع» تعیین کنیم تا نه به صورت خودکار و نه به صورت دستی قابل اجرا باشد باید آن را ماسک کنیم. برای این کار یک دستور به نام mask وجود دارد که واحد ما را به dev/null/ متصل می کند بنابراین آن واحد دیگر هیچ وقت اجرا نمی شود. ممکن است بگویید چرا باید چنین قابلیتی را داشته باشیم؟ فرض کنید دو وب سرور مختلف (Nginx و Apache) روی سیستم شما نصب شده است. هر دو وب سرور به صورت پیش فرض پورت ۸۰ را اشغال می کنند بنابراین با هم تضاد دارند و کار یکدیگر را مختل می کنند. راه حل اول این است که یکی از دو وب سرور را حذف کنید اما راه حل بهتری نیز وجود دارد. شما می توانید یکی از آن ها را ماسک کنید تا اصلا اجرا نشود و کار دیگری را مختل نکند. با این کار هیچ کدام از وب سرورها از سیستم شما حذف نمی شود و در آینده اگر بخواهید آن را دوباره فعال کنید آزاد هستید.

sudo systemctl mask nginx.service

با اجرای این دستور nginx کاملا ماسک یا غیر فعال می شود. حالا دستور لیست کردن فایل های واحد را اجرا می کنیم:

sudo systemctl list-unit-files

در نتیجه نمایش داده شده به دنبال nginx بگردید. زمانی که آن را پیدا کنید خواهید دید که وضعیت آن روی حالت masked قرار دارد:

// دیگر واحد ها

kmod-static-nodes.service              static 

ldconfig.service                       static 

mandb.service                          static 

messagebus.service                     static 

nginx.service                          masked

quotaon.service                        static 

rc-local.service                       static 

rdisc.service                          disabled

rescue.service                         static

// دیگر واحد ها

در حال حاضر حتی اگر سعی کنید به صورت دستی nginx را اجرا کنید، ناموفق خواهید بود:

sudo systemctl start nginx.service

نتیجه اجرای این دستور به شکل زیر خواهد بود:

Failed to start nginx.service: Unit nginx.service is masked.

یعنی این سرویس ماسک شده است و قابلیت اجرا ندارد. اگر واقعا می خواهید nginx را دوباره فعال کنید باید از دستور unmask استفاده نمایید تا آن را از حالت ماسک شده خارج کنید: