Xizmatlarni boshqarish

systemd unitlari va targetlari maqolasida unit fayllari qanday tuzilgani va ular bir-biriga qanday bog'liqligi ko'rib chiqildi. Endi bu bilimni kundalik amaliyotga qo'llash vaqti keldi: .service unit’larini ishga tushirish, to'xtatish, boot paytida yoqish va ularning joriy holatini tekshirish. Bu Linux administratori eng ko'p bajaradigan vazifalardan biri: veb-server, ma’lumotlar bazasi yoki o'zingizning backend ilovangiz — hammasi aynan bir xil buyruqlar to'plami orqali boshqariladi.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

• systemctl start/stop/restart/reload o'rtasidagi farqni tushuntirish;
• enable/disable bilan boot paytida avtomatik ishga tushishni sozlash;
• systemctl status chiqishidagi har bir maydonni o'qish;
• is-active, is-enabled, is-failed kabi skript uchun qulay tekshiruvlardan foydalanish;
• mask/unmask nega mavjudligini va u disable dan qanday farq qilishini tushuntirish.

Xizmatni ishga tushirish, to'xtatish va qayta ishga tushirish

sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl restart nginx

Bu uchtasi o'z-o'zidan tushunarli: start xizmatni ishga tushiradi, stop uni to'xtatadi, restart esa uni butunlay to'xtatib, qayta ishga tushiradi. restart konfiguratsiyasini ishga tushishda o'qiydigan har qanday xizmat uchun ishlaydi, lekin u jarayonni qayta yaratishdan oldin butunlay o'ldirgani uchun xizmat bir lahzaga bo'lsa ham mavjud bo'lmay qoladi.

sudo systemctl reload nginx

reload esa aksincha, xizmatni to'xtatmasdan uni konfiguratsiyasini qayta o'qishga majbur qiladi. Agar xizmat buni qo'llab-quvvatlasa, bu konfiguratsiya o'zgarishini uzilishsiz qo'llashning standart usuli. Har bir xizmat ham reload ni qo'llab-quvvatlamaydi; bunday holatda systemctl reload nginx darhol xato beradi va buning o'rniga restart ishlatishga to'g'ri keladi.

Boot paytida avtomatik ishga tushirish: enable va disable

start/stop faqat joriy sessiyaga ta’sir qiladi — qayta yuklashdan keyin xizmat avvalgi holatiga qaytadi. Xizmat har bir boot’da avtomatik ishga tushishi alohida buyruqlar juftligi bilan boshqariladi:

sudo systemctl enable nginx
sudo systemctl disable nginx

enable systemd unitlari va targetlari maqolasida ko'rilgan unit fayli [Install] bo'limidagi WantedBy= qiymatiga asoslanib, tegishli target katalogida (masalan, /etc/systemd/system/multi-user.target.wants/) symlink yaratadi. disable esa shu symlink’ni olib tashlaydi.

enable va start ikki mustaqil amal, ya’ni to'rt xil birikma bo'lishi mumkin:

Ikkalasini birdaniga bajarishning qulay qisqa shakli:

sudo systemctl enable --now nginx

Bu enable va start ni bitta chaqiruvda bajaradi. Yangi xizmatni sozlashda eng ko'p ishlatiladigan shakl shu va O'z systemd xizmatini yaratish maqolasida ham aynan shu andoza ishlatiladi.

Xizmat holatini tekshirish

systemctl status nginx

● nginx.service - A high performance web server and reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Fri 2026-07-24 09:02:11 UTC; 1h 20min ago
       Docs: man:nginx(8)
   Main PID: 1842 (nginx)
      Tasks: 3 (limit: 4665)
     Memory: 4.2M
        CPU: 128ms
     CGroup: /system.slice/nginx.service
             ├─1842 "nginx: master process /usr/sbin/nginx"
             └─1843 "nginx: worker process"

Muhim maydonlar:

• Loaded — unit fayli topilganmi va uning enabled/disabled holati;
• Active — asosiy holat (active, inactive, failed) va qavs ichidagi batafsilroq holat (running, exited, dead);
• Main PID — xizmatning asosiy jarayon identifikatori;
• CGroup — xizmatga tegishli barcha jarayonlar, ya’ni /proc fayl tizimi maqolasida ko'rilgan jarayonlar daraxtining systemd darajasidagi ko'rinishi.

systemctl status oxirgi bir nechta log qatorini ham ko'rsatadi, lekin to'liq tarix journalctl maqolasida ko'riladigan maxsus vosita bilan o'qiladi.

Skript uchun qulay holat tekshiruvlari

Avtomatlashtirilgan skriptga faqat chiqish kodi kerak bo'lganda interaktiv status o'rniga quyidagilar qulayroq:

systemctl is-active nginx
echo $?

active
0

Bu buyruqlar Bash skript asoslari modulida ko'riladigan health-check va monitoring skriptlarining asosiy qurilish bloki — chiqish kodi if systemctl is-active --quiet nginx; then ... fi kabi shartlarni yozish imkonini beradi.

mask va unmask: disable dan kuchliroq

sudo systemctl mask apache2

disable faqat avtomatik ishga tushishni o'chiradi — xizmatni baribir systemctl start bilan qo'lda ishga tushirish mumkin. mask esa unit faylini /dev/null ga symlink qiladi, shuning uchun uni umuman — na qo'lda, na boshqa unit’ning bog'liqligi sifatida — ishga tushirib bo'lmaydi:

sudo systemctl start apache2

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

To'siqni olib tashlash:

sudo systemctl unmask apache2

mask odatda ikki xizmat haqiqatan ziddiyatga kirganda (masalan, bitta serverda apache2 va nginx ikkalasi ham bitta port’ni band qilishga urinsa) yoki xavfsizlik siyosati muayyan xizmatni butunlay to'sib qo'yishni talab qilganda ishlatiladi.

Keng tarqalgan xatolar

Xizmatni yoqib, uni ishga tushirishni unutish

Xizmat yoqilgan, lekin hali ishlamayapti — chunki enable faqat keyingi boot’ga ta’sir qiladi. Uni darhol ishga tushirish uchun enable --now yoki alohida start dan foydalaning.

restart va reload ni adashtirish

Yuqori trafikli production xizmatida oddiy konfiguratsiya o'zgarishi uchun restart ishlatish, xizmat aslida reload ni qo'llab-quvvatlasa ham, qisqa uzilishga sabab bo'ladi. Imkoni boricha reload yoki reload-or-restart ni afzal ko'ring.

disable ni mask bilan adashtirish

disable qilingan xizmatni boshqa unit baribir bog'liqlik sifatida (masalan, Requires= orqali) ishga tushirishi mumkin. Agar xizmat hech qanday sharoitda hech qachon ishga tushmasligi kerak bo'lsa, mask dan foydalaning.

[Install] bo'limi yo'q unit’ni enable qilishga urinish

sudo systemctl enable mytimer.service

The unit files have no installation config (WantedBy=, RequiredBy=, Also=, Alias=
settings in the [Install] section, and DefaultInstance= for template units).

enable unit’ning [Install] bo'limidagi WantedBy=/RequiredBy= tasvirlagan symlink’ni yaratish orqali ishlaydi. Bunday bo'limi bo'lmagan unit’ni shunchaki yoqib bo'lmaydi va buyruq indamay hech narsa qilmasdan qolmaydi, yuqoridagi xabar bilan xato beradi. Yechim — [Install] bo'limini qo'shish (O'z systemd xizmatini yaratish maqolasiga qarang). Faqat boshqa unit’ning bog'liqligi sifatida chaqiriladigan unit’da [Install] bo'limi bo'lmasligi qonuniy va uni to'g'ridan-to'g'ri yoqish mo'ljallanmagan.

Mashqlar

1. Sinov VM’ida mavjud xizmatni (masalan, cron) stop, status, start orqali o'tkazing va har bir qadamda Active maydoni qanday o'zgarishini kuzating.
2. Xuddi shu xizmatni disable qiling, qayta yuklang (yoki systemctl daemon-reload bilan simulyatsiya qiling) va is-enabled/is-active natijalari qanday farq qilishini tushuntiring.
3. Zararsiz xizmatni mask qiling, uni start qilishga urinib, xato xabarini o'qing, so'ng unmask bilan ortga qaytaring.
4. systemctl is-active --quiet nginx && echo "running" || echo "not running" kabi shart yozing va is-active ning chiqish kodi amalda qanday ishlatilishini kuzating.

Mashqni bajardim deyish uchun: yuqoridagi jadvaldagi to'rtta yoqilgan/ishlayotgan birikmasining har biridagi xizmat uchun uni boshqa birikmaga aynan qaysi buyruq o'tkazishini ayta olishingiz kerak.

Xulosa

start/stop/restart/reload xizmatning joriy holatini, enable/disable esa uning boot paytida avtomatik ishga tushishini boshqaradi — bular ikki mustaqil o'lchov bo'lib, ko'pincha enable --now bilan birlashtiriladi. systemctl status batafsil ko'rinishni beradi, is-active/is-enabled/is-failed esa skriptlar uchun qisqa, chiqish kodiga qulay tekshiruvlarni taqdim etadi. mask disable dan farqli o'laroq, xizmatning har qanday yo'l bilan ishga tushishini to'sib qo'yadi. Keyingi maqola — O'z systemd xizmatini yaratish xuddi shu buyruqlarni mavjud xizmatga emas, o'zingiz yozadigan yangi .service fayliga qo'llaydi.

Manbalar

• man7.org: systemctl(1)
• freedesktop.org: systemd.unit(5)
• freedesktop.org: systemd.service(5)