systemd - ilovani xizmatga aylantirish - Linux server administratsiyasi

Ilovani nohup ./ilova & bilan ishga tushirish - vaqtinchalik yechim. Server qayta yuklansa u ko'tarilmaydi, yiqilsa qayta turmaydi, jurnali qayerdaligi noma'lum va uni to'xtatganda bolalari qolib ketadi.

systemd bularning barchasini hal qiladi.

Unit fayl #

Terminal

systemctl stop sr-sinov 2>/dev/null
systemctl disable sr-sinov 2>/dev/null
systemctl reset-failed sr-sinov 2>/dev/null
rm -f /etc/systemd/system/sr-sinov.service

id sr-ilova >/dev/null 2>&1 || useradd --system --no-create-home \
    --shell /usr/sbin/nologin sr-ilova
mkdir -p /opt/sr-sinov
cat > /opt/sr-sinov/ilova.sh <<'EOF'
#!/bin/bash
echo "ilova ishga tushdi"
sleep 2
echo "ish tugadi"
EOF
chmod 755 /opt/sr-sinov/ilova.sh

cat > /etc/systemd/system/sr-sinov.service <<'EOF'
[Unit]
Description=Softromeda sinov xizmati
After=network.target

[Service]
Type=simple
ExecStart=/opt/sr-sinov/ilova.sh
Restart=no
User=sr-ilova
Group=sr-ilova
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
MemoryMax=64M

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload

Unit fayl uchta bo'limdan iborat:

Uch bo'lim: kim bilan, qanday, va qachon

Sintaksisni tekshirish #

Terminal

systemd-analyze verify /etc/systemd/system/sr-sinov.service && echo "unit fayl to'g'ri"

Natija

unit fayl to'g'ri

systemd-analyze verify - daemon-reload dan oldin

Bu buyruq unit faylni ishga tushirmasdan tekshiradi: xato kalit so'zlar, mavjud bo'lmagan ExecStart yo'li, noto'g'ri bog'liqliklar.

Jim chiqish - hammasi joyida degani.

Bu 7-bo'limdagi visudo -c va 8-bo'limdagi sshd -t bilan bir xil odat: sozlamani ishga tushirishdan oldin tekshirish.

Serverda bu uchta buyruqni yodda tuting:

Nima	Tekshiruv
`sudoers`	`visudo -cf fayl`
`sshd_config`	`sshd -t -f fayl`
`.service`	`systemd-analyze verify fayl`
`nginx.conf`	`nginx -t`

Ishga tushirish va holat #

Terminal

systemctl start sr-sinov
sleep 1
systemctl is-active sr-sinov
sleep 3
systemctl is-active sr-sinov

Natija

active
inactive

Xizmat ishga tushdi, ikki soniyadan keyin skript tugadi va Restart=no bo'lgani uchun qayta ko'tarilmadi.

Buyruq	Vazifa
`systemctl start`	Hozir ishga tushirish
`systemctl stop`	To'xtatish
`systemctl restart`	To'xtatib, qayta ishga tushirish
`systemctl reload`	Uzmasdan sozlamani qayta o'qish
`systemctl enable`	Yuklanishda avtomatik ishga tushsin
`systemctl disable`	Avtomatik ishga tushmasin
`systemctl status`	Batafsil holat va oxirgi jurnal
`systemctl is-active`	Skript uchun qisqa javob

start va enable - ikki xil ish

Bu xatoni deyarli har bir administrator bir marta qiladi.

Buyruq	Hozir ishlaydimi	Qayta yuklashdan keyin
`start`	Ha	Yo'q
`enable`	Yo'q	Ha
`enable --now`	Ha	Ha

Klassik voqea: xizmat sozlandi, ishlayapti, hamma xursand. Uch oydan keyin server qayta yuklanadi - va xizmat ko'tarilmaydi.

Shuning uchun doim systemctl enable --now xizmat ishlating, va sozlagandan keyin systemctl is-enabled bilan tekshiring.

Terminal

systemctl enable sr-sinov > /dev/null 2>&1
systemctl is-enabled sr-sinov
systemctl disable sr-sinov > /dev/null 2>&1
systemctl is-enabled sr-sinov

Natija

enabled
disabled

Jurnal #

Xizmatning stdout va stderr chiqishi avtomatik jurnalga tushadi - hech qanday > log.txt kerak emas.

Terminal

systemctl start sr-sinov
sleep 3
journalctl -u sr-sinov -n 4 --no-pager -o cat

Natija

Started sr-sinov.service - Softromeda sinov xizmati.
ilova ishga tushdi
ish tugadi
sr-sinov.service: Deactivated successfully.

echo bilan chiqarilgan ikki satr o'rtada turibdi - systemd ularni o'zi yig'ib oldi.

Ilovada fayl jurnalini yozmang

Ko'p ilovalar o'z jurnal faylini yaratadi: /var/log/ilova.log. Serverda bu keraksiz murakkablik:

Fayl jurnali	`systemd` jurnali
Aylanishini o'zingiz sozlaysiz	Avtomatik
Diskni to'ldirishi mumkin	Chegarasi bor
Xizmat bilan bog'lanmagan	`-u xizmat` bilan filtrlash
Har ilovada har xil format	Yagona format va vaqt belgisi

To'g'ri yondashuv: ilova shunchaki stdout ga yozsin, qolganini systemd bajaradi. Bu konteynerlardagi yondashuv bilan ham bir xil.

13-bo'limda journalctl ni batafsil ko'ramiz.

Avtomatik qayta ishga tushirish #

Bu systemd ning eng qimmatli xususiyati.

`Restart=`	Qachon qayta ishga tushadi
`no`	Hech qachon (standart)
`on-failure`	Faqat xato bilan tugasa - odatda kerakli
`always`	Har doim, hatto toza chiqishda ham
`on-abnormal`	Signal yoki taymaut bo'lsa

Terminal

mkdir -p /etc/systemd/system/sr-sinov.service.d
cat > /etc/systemd/system/sr-sinov.service.d/qayta.conf <<'EOF'
[Service]
Restart=on-failure
RestartSec=1
EOF
systemctl daemon-reload
systemctl show sr-sinov -p Restart -p RestartUSec

Natija

Restart=on-failure
RestartUSec=1s

.d/ katalogi - asl faylga tegmasdan o'zgartirish

Paket bilan kelgan unit faylni (/lib/systemd/system/nginx.service) tahrirlamang - keyingi yangilanishda o'zgarishingiz yo'qoladi.

To'g'ri yo'l - qo'shimcha fayl:

Usul	Natija
`systemctl edit nginx`	`.d/override.conf` yaratadi va ochadi
`systemctl edit --full nginx`	To'liq nusxani `/etc` ga ko'chiradi
`systemctl cat nginx`	Asl fayl va barcha qo'shimchalarni ko'rsatadi
`systemctl revert nginx`	Barcha o'zgarishlarni bekor qiladi

systemctl cat - eng foydalisi: u yakuniy sozlamani qaysi fayldan kelganini ko'rsatib beradi.

Faylni qo'lda yaratsangiz, systemctl daemon-reload ni unutmang - aks holda systemd eski nusxani ishlatadi.

Restart=always bilan cheksiz sikl

Xizmat ishga tushishi bilanoq yiqilsa (masalan sozlama xato), Restart=always uni cheksiz qayta ishga tushiradi - sekundiga o'nlab marta. Jurnal to'ladi, protsessor band bo'ladi.

systemd bunga qarshi himoyaga ega:

Natija

StartLimitIntervalSec=10
StartLimitBurst=5

Ya'ni 10 soniyada 5 martadan ko'p ishga tushsa, systemd to'xtaydi va xizmatni failed holatiga qo'yadi.

Shu sababli systemctl status da "start request repeated too quickly" xabarini ko'rsangiz - bu systemd sizni himoya qilgani, nosozlik emas. Haqiqiy sababni jurnaldan qidiring.

RestartSec= ni ham nolga qo'ymang - kamida 1-5 soniya bering.

Resurs cheklovlari #

Terminal

systemctl show sr-sinov -p MemoryMax -p User -p Group

Natija

MemoryMax=67108864
User=sr-ilova
Group=sr-ilova

64 MB bayt hisobida - systemd qiymatni cgroup uchun aylantirdi.

Sozlama	Vazifa
`MemoryMax=512M`	Qattiq chegara - oshsa o'ldiriladi
`MemoryHigh=384M`	Yumshoq chegara - sekinlashtiradi
`CPUQuota=50%`	Yarim yadrodan ko'p emas
`TasksMax=100`	Jarayonlar soni
`LimitNOFILE=65535`	Ochiq fayllar (11-bo'lim)
`OOMScoreAdjust=-500`	OOM Killer uchun himoya

MemoryMax - ma'lumotlar bazasini himoyalash usuli

11-bo'limda ko'rganimizdek, xotira tugaganda OOM Killer odatda MySQL ni tanlaydi - u eng ko'p xotira egallaydi.

Yechim - aybdorni cheklash, qurbonni emas:

Natija

[Service]
MemoryMax=512M

Endi xotira sizib ketayotgan ilova o'z chegarasida o'ldiriladi. Ma'lumotlar bazasi tegilmaydi, sayt ishlashda davom etadi, va jurnalda aniq sabab qoladi.

MySQL ni esa teskari tomondan himoyalang:

Natija

[Service]
OOMScoreAdjust=-500

Xizmatni izolyatsiyalash #

Bu sozlamalar buzilgan xizmatning zarar doirasini toraytiradi.

Terminal

systemctl show sr-sinov -p NoNewPrivileges -p PrivateTmp -p ProtectSystem

Natija

PrivateTmp=yes
ProtectSystem=strict
NoNewPrivileges=yes

Sozlama	Nima beradi
`User=`	root emas - eng muhimi
`NoNewPrivileges=true`	`setuid` orqali huquq oshirib bo'lmaydi
`PrivateTmp=true`	O'z `/tmp` si - boshqalarnikini ko'rmaydi
`ProtectSystem=strict`	Butun fayl tizimi faqat o'qish
`ProtectHome=true`	`/home` ko'rinmaydi
`ReadWritePaths=/var/lib/ilova`	Faqat shu katalogga yozadi
`PrivateDevices=true`	Qurilma fayllari yo'q
`CapabilityBoundingSet=`	Yadro imkoniyatlarini cheklash

ProtectSystem=strict bilan xizmat yoza olmay qoladi

strict butun fayl tizimini faqat o'qish rejimiga qo'yadi - /var va /etc ni ham.

Agar xizmatingiz fayl yozishi kerak bo'lsa, aniq ruxsat bering:

Natija

ProtectSystem=strict
ReadWritePaths=/var/lib/ilova /var/log/ilova

Bu "hammasi taqiq, keraklisi ruxsat" yondashuvi - sudo da ham, xavfsizlik devorida ham (16-bo'lim) bir xil g'oya.

Xizmatning izolyatsiya darajasini baholash:

Terminal

systemd-analyze security sr-sinov

U 0 dan 10 gacha ball beradi va qaysi sozlama yetishmayotganini ro'yxat qilib ko'rsatadi.

`Type=` ni to'g'ri tanlash #

`Type=`	Qachon
`simple`	Dastur old planda qoladi - eng ko'p uchraydigan
`exec`	`simple` kabi, lekin ishga tushishini kutadi
`forking`	Dastur o'zi fonga o'tadi (eski uslub)
`oneshot`	Bir marta ishlaydi va tugaydi (migratsiya, tozalash)
`notify`	Dastur "tayyorman" deb `systemd` ga xabar beradi

Type=forking - eng ko'p xatoga sabab bo'ladigan tanlov

Zamonaviy dasturlarni fonga o'tkazmang. systemd ning o'zi jarayonni fonda ushlaydi.

Agar dasturingizda --daemon yoki -d bayrog'i bo'lsa, uni ishlatmang va Type=simple qoldiring.

Type=forking ishlatilganda systemd qaysi jarayon asosiy ekanini bilmay qoladi va PIDFile= kerak bo'ladi. Bu esa poyga holatlariga olib keladi: systemd PID faylni yaratilishidan oldin o'qishi mumkin.

Nginx bunga istisno - u haqiqatan ham fork qiladi va Type=forking bilan PIDFile= ishlatadi (17-bo'lim).

Xizmat yiqilganda #

Buyruq	Nima ko'rsatadi
`systemctl status xizmat`	Holat + oxirgi 10 satr jurnal
`systemctl --failed`	Barcha yiqilgan xizmatlar
`journalctl -u xizmat -n 50`	Batafsil jurnal
`journalctl -u xizmat -p err`	Faqat xatolar
`systemctl reset-failed xizmat`	`failed` belgisini tozalash
`systemctl show xizmat -p Result`	Yiqilish sababi

Terminal

systemctl start sr-sinov
sleep 3
systemctl show sr-sinov -p Result -p ExecMainStatus -p NRestarts

Natija

Result=success
NRestarts=0
ExecMainStatus=0

Serverga kirganda birinchi buyruq

Terminal

systemctl --failed

Bu bitta buyruq "nima buzilgan?" degan savolga darhol javob beradi. Ro'yxat bo'sh bo'lsa - systemd darajasida hamma narsa joyida.

Uni serverga kirganda bajariladigan odatiy uchlikka qo'shing:

Buyruq	Savol
`df -h`	Disk to'lmaganmi?
`systemctl --failed`	Xizmat yiqilmaganmi?
`journalctl -p err -b`	Yuklanishdan beri xatolar bormi?

Amaliy topshiriq

Uchta bo'limli minimal unit fayl yozing.
systemd-analyze verify bilan tekshiring.
start qiling va is-active bilan holatni ko'ring.
enable va disable farqini is-enabled bilan tasdiqlang.
journalctl -u bilan ilovaning echo chiqishini toping.
.d/ katalogida Restart=on-failure qo'shing.
systemctl show bilan sozlama qo'llanganini tekshiring.
MemoryMax va User qiymatlarini tasdiqlang.
ProtectSystem=strict qo'ying va ReadWritePaths bilan yozishga ruxsat bering.
systemd-analyze security bilan ballni ko'ring.

Xulosa #

[Unit] - munosabat, [Service] - qanday ishlash, [Install] - enable uchun.
[Install] bo'lmasa systemctl enable ishlamaydi.
start hozir, enable yuklanishda - enable --now ikkalasi.
Sozlamani systemd-analyze verify bilan oldindan tekshiring.
stdout avtomatik jurnalga tushadi - ilovada fayl jurnali yozmang.
Restart=on-failure odatda to'g'ri tanlov; always sikl yaratishi mumkin.
Paket unitini tahrirlamang - systemctl edit va .d/ ishlating.
Fayl qo'lda o'zgartirilsa - daemon-reload shart.
MemoryMax aybdorni cheklaydi, OOMScoreAdjust qurbonni himoyalaydi.
Type=forking dan qoching; zamonaviy dastur old planda qolsin.

Keyingi bo'limda jurnalni chuqurroq o'rganamiz: journalctl filtrlari, doimiy saqlash va jurnal aylanishi.

Unit fayl #

Sintaksisni tekshirish #

Ishga tushirish va holat #

Jurnal #

Avtomatik qayta ishga tushirish #

Resurs cheklovlari #

Xizmatni izolyatsiyalash #

Type= ni to'g'ri tanlash #

Xizmat yiqilganda #

Xulosa #

Xatolik topdingizmi?

`Type=` ni to'g'ri tanlash #