5. systemd va xizmatlar — 25 ta masala

Faqat laboratoriya mashinasida

Xizmatlarni to'xtatish va o'chirish ish serverida uzilishga olib keladi. Mashqlarni virtual mashinada bajaring. Misollarda ssh/nginx ishlatilgan; sizda o'rnatilgan boshqa xizmat nomini qo'ying.

Xizmatlarni boshqarish

1. ssh xizmatining holatini ko'rsating va Loaded hamda Active qatorlarini izohlang.
Misol: Active: active (running) since ...

Yechim

systemctl status ssh

Loaded — unit fayli topilgani va enabled (yuklashda ishga tushadi) yoki disabled. Active — hozirgi holat: active (running), inactive (dead) yoki failed. RHEL oilasida xizmat nomi sshd.

2. Skriptda ishlatish uchun xizmat faolligini, yoqilganligini va muvaffaqiyatsizligini alohida tekshiring.
Misol: active, enabled.

Yechim

systemctl is-active ssh
systemctl is-enabled ssh
systemctl is-failed ssh

Bu buyruqlar natijani matn va chiqish kodi (0 — ha) bilan qaytaradi: if systemctl is-active --quiet ssh; then ... shaklida ishlatiladi.

3. restart va reload farqini ko'rsating. Qaysi birini qachon tanlaysiz?
Misol: reload jarayonni o'ldirmaydi.

Yechim

sudo systemctl reload nginx
sudo systemctl restart nginx

restart — to'xtatib, qayta ishga tushiradi (ulanishlar uziladi). reload — jarayon ishlayotgan holda konfiguratsiyani qayta o'qitadi (ExecReload= bo'lsa). Avval konfiguratsiyani tekshiring (nginx -t), keyin reload. Xizmat reload ni qo'llamasa, systemctl reload-or-restart ishlatiladi.

4. Xizmatni darhol ishga tushiring va yuklashda avtomatik ishlashini ham yoqing, bitta buyruq bilan.
Misol: Created symlink /etc/systemd/system/multi-user.target.wants/...

Yechim

sudo systemctl enable --now nginx

enable o'zi xizmatni ishga tushirmaydi, start esa yuklashda avtomatik ishlashni yoqmaydi. Bu ikki mustaqil narsa.

5. mask va disable farqini ko'rsating.
Misol: maskalangan xizmatni start qilish xato beradi.

Yechim

sudo systemctl mask nginx
sudo systemctl start nginx
sudo systemctl unmask nginx

disable — faqat yuklashda avtomatik ishga tushishni o'chiradi, qo'lda start ishlaydi. mask — unit'ni /dev/null ga yo'naltiradi: uni qo'lda ham, boshqa xizmat bog'liqligi orqali ham ishga tushirib bo'lmaydi (Unit nginx.service is masked.).

6. Hozir muvaffaqiyatsiz bo'lgan barcha xizmatlarni ro'yxatlang.
Misol: 0 loaded units listed. (sog'lom tizimda).

Yechim

systemctl --failed

7. Hozir ishlayotgan barcha xizmatlarni ko'rsating, so'ng o'rnatilgan, lekin yoqilmaganlarini toping.
Misol: birinchisida faqat running, ikkinchisida disabled holatlar.

Yechim

systemctl list-units --type=service --state=running
systemctl list-unit-files --type=service --state=disabled

list-units — xotiradagi (yuklangan) unit'lar, list-unit-files — diskda mavjud fayllar.

8. Xizmatning haqiqiy unit faylini (drop-in lar bilan) ko'ring.
Misol: # /lib/systemd/system/ssh.service sarlavhasi bilan fayl.

Yechim

systemctl cat ssh

9. Xizmatning asosiy PID i va holatini skriptga qulay (key=value) ko'rinishda oling.
Misol: MainPID=1021, ActiveState=active.

Yechim

systemctl show ssh -p MainPID -p ActiveState

10. Standart boot target'ni ko'ring, so'ng matnli (GUI'siz) rejimga o'zgartiring.
Misol: graphical.target → multi-user.target.

Yechim

systemctl get-default
sudo systemctl set-default multi-user.target

set-default keyingi yuklashda kuchga kiradi. Hozirgi sessiyada o'tish uchun systemctl isolate multi-user.target.

O'z xizmatingizni yaratish

11. sleep infinity ni xizmat sifatida ishga tushiring (hello.service).
Misol: systemctl status hello → active (running).

Yechim

sudo tee /etc/systemd/system/hello.service <<'EOF'
[Unit]
Description=Hello demo xizmati

[Service]
ExecStart=/bin/sleep infinity

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now hello

Unit fayli o'zgargach daemon-reload shart, aks holda systemd eski ta'rifni ishlatadi. Shaxsiy unit'lar /etc/systemd/system/ ga yoziladi (paket unit'lari /lib/systemd/system/).

12. hello jarayoni xato bilan tugasa, 5 soniyadan keyin qayta ishga tushsin.
Misol: kill -9 PID dan keyin xizmat o'zi tiklanadi.

Yechim

[Service]
ExecStart=/bin/sleep infinity
Restart=on-failure
RestartSec=5

Keyin sudo systemctl daemon-reload && sudo systemctl restart hello. Restart=always jarayon toza (0) chiqsa ham qayta ishga tushiradi; on-failure faqat xato yoki signal bilan tugaganda.

13. Xizmat root emas, svc-app foydalanuvchisi ostida, /opt/app katalogida ishlasin.
Misol: ps -o user,cmd -p MainPID → svc-app.

Yechim

[Service]
User=svc-app
Group=svc-app
WorkingDirectory=/opt/app
ExecStart=/opt/app/run.sh

Xizmatni minimal huquq bilan ishlatish xavfsizlikning asosi: u buzilsa, hujumchi root bo'lib qolmaydi.

14. Xizmatga muhit o'zgaruvchilarini alohida fayldan bering.
Misol: /etc/app.env ichida PORT=8080.

Yechim

[Service]
EnvironmentFile=/etc/app.env
ExecStart=/opt/app/run.sh

Maxfiy ma'lumotli faylga chmod 600 bering. EnvironmentFile dagi qiymatlar shell tomonidan emas, systemd tomonidan o'qiladi.

15. Paketdan kelgan unit faylini o'zgartirmasdan, ustidan sozlama qo'shing.
Misol: /etc/systemd/system/nginx.service.d/override.conf yaratiladi.

Yechim

sudo systemctl edit nginx

Editor ochiladi, siz faqat o'zgartiriladigan qatorlarni yozasiz ([Service] bo'limi bilan). Paket yangilansa, asl fayl almashadi, sizning override.conf esa saqlanadi.

16. Wants=, Requires= va After= ning farqini ayting va app.service ni postgresql.service dan keyin ishga tushiring.
Misol: After=postgresql.service + Wants=postgresql.service.

Yechim

[Unit]
After=postgresql.service
Wants=postgresql.service

After= faqat tartibni belgilaydi, bog'liqlikni emas. Wants= — yumshoq bog'liqlik (u ishga tushmasa ham biz davom etamiz), Requires= — qattiq (u tushmasa, biz ham ishga tushmaymiz).

Loglar va diagnostika

17. nginx xizmatining oxirgi 50 ta log qatorini ko'ring va yangilarini jonli kuzating.
Misol: -- Logs begin at ... va yangi qatorlar.

Yechim

journalctl -u nginx -n 50
journalctl -u nginx -f

18. Oxirgi 1 soatdagi xato darajasidagi (va undan jiddiy) loglarni ko'rsating.
Misol: faqat err, crit, alert, emerg xabarlar.

Yechim

journalctl --since "1 hour ago" -p err

19. Oldingi yuklanish (boot) loglarini ko'ring. Agar chiqmasa, sababini toping.
Misol: journalctl -b -1. Chiqmasa: no persistent journal.

Yechim

journalctl --list-boots
journalctl -b -1

Standart bo'yicha ba'zi tizimlarda jurnal faqat xotirada (/run/log/journal) saqlanadi va qayta yuklanganda yo'qoladi. Doimiy qilish: sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald.

20. Jurnal diskda qancha joy egallayotganini ko'ring va 7 kundan eskisini tozalang.
Misol: Archived and active journals take up 512.0M.

Yechim

journalctl --disk-usage
sudo journalctl --vacuum-time=7d

Doimiy cheklov: /etc/systemd/journald.conf da SystemMaxUse=500M.

21. Xizmat status=203/EXEC bilan yiqildi. Bu nimani bildiradi va nimani tekshirasiz?
Misol: code=exited, status=203/EXEC.

Yechim

systemctl status hello
journalctl -u hello -n 20
ls -l /opt/app/run.sh

203/EXEC — systemd ExecStart= dagi dasturni ishga tushira olmadi. Odatiy sabablar: yo'l xato, fayl chmod +x qilinmagan, noto'g'ri shebang yoki fayl tizimi noexec bilan o'rnatilgan. 200/CHDIR — WorkingDirectory mavjud emas, 217/USER — User= topilmadi.

22. Xizmat yuklashni qancha sekinlatayotganini toping.
Misol: 5.231s NetworkManager-wait-online.service.

Yechim

systemd-analyze
systemd-analyze blame | head
systemd-analyze critical-chain

blame — har bir unit sarflagan vaqt, critical-chain — yuklashni aslida kechiktirgan zanjir.

23. Yozgan unit faylingizni ishga tushirmasdan tekshiring.
Misol: sintaksis xatosi bo'lsa Unknown key name ogohlantirishi.

Yechim

systemd-analyze verify /etc/systemd/system/hello.service

24. crond o'rniga har kuni 02:30 da backup.sh ni ishga tushiruvchi timer yozing.
Misol: systemctl list-timers da backup.timer ko'rinadi.

Yechim

/etc/systemd/system/backup.service:

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

/etc/systemd/system/backup.timer:

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers

25. Persistent=true nimani o'zgartiradi va cron'dan farqi nima?
Misol: server soat 02:30 da o'chiq bo'lsa, yoqilgach job bajariladi.

Yechim

systemctl list-timers --all
journalctl -u backup.service

Persistent=true — oxirgi ishga tushish vaqtini diskda saqlaydi, o'tkazib yuborilgan ishni yoqilganda darhol bajaradi. Oddiy cron o'tkazib yuborilgan ishni takrorlamaydi. Timer'ning yana afzalligi: natijasi journalctl -u da yig'ilgan.