systemd troubleshooting

Shu paytgacha ko'rilgan barcha vositalar — Xizmatlarni boshqarish, O'z systemd xizmatini yaratish va journalctl — endi bitta amaliy maqsad uchun birlashadi: xizmat nega kutilganidek ishlamayotganini sinov va xato yo'li bilan emas, tizimli ravishda aniqlash. Bu maqola tasodifiy taxminlarga emas, aniq ketma-ketlikka asoslangan diagnostika yondashuvini ko'rsatadi — ishdan chiqqan unit’larni topishdan tortib boot vaqtini tahlil qilish va bog'liqlik muammolarini aniqlashgacha.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

• tizimdagi barcha ishdan chiqqan unit’larni systemctl --failed bilan bir yo'la ko'rish;
• systemctl status dagi chiqish kodi va signal ma’lumotlarini o'qib, ehtimoliy sababni aniqlash;
• boot vaqtini systemd-analyze blame va critical-chain bilan tahlil qilish;
• unit bog'liqliklarini systemctl list-dependencies bilan ko'zdan kechirish;
• xizmat nosozligini aniqlash uchun izchil, bosqichma-bosqich jarayonni qo'llash.

Ishdan chiqqan unit’larni topish

Nechta xizmatda muammo borligini va qaysilarida ekanini ko'rishning eng tez usuli:

systemctl --failed

  UNIT                    LOAD   ACTIVE SUB    DESCRIPTION
● backend-demo.service    loaded failed failed Backend demo application

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed.

Bu buyruq systemctl list-units --state=failed ning qisqa shakli. Xizmatlarni boshqarish maqolasidagi is-failed bitta unit uchun ishlaganidek, --failed butun tizim bo'yicha umumiy ko'rinishni beradi. Aniq bo'lmagan muammo paydo bo'lganda har doim birinchi buyruq aynan shu bo'lishi kerak.

Diagnostika jarayoni, bosqichma-bosqich

Ishdan chiqqan unit topilgach, odatda quyidagi ketma-ketlik sababni aniqlab beradi:

flowchart TD
    A["systemctl --failed"] --> B["systemctl status <unit>"]
    B --> C["journalctl -u <unit> -n 50"]
    C --> D{"Is the cause clear?"}
    D -->|No| E["systemctl list-dependencies <unit>"]
    D -->|Yes| F["Fix and restart"]
    E --> F

1-qadam: systemctl status bilan umumiy ko'rinish

systemctl status backend-demo.service

● backend-demo.service - Backend demo application
     Loaded: loaded (/etc/systemd/system/backend-demo.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Fri 2026-07-24 12:01:15 UTC; 30s ago
    Process: 7120 ExecStart=/usr/bin/python3 /opt/backend-demo/app.py (code=exited, status=1/FAILURE)
   Main PID: 7120 (code=exited, status=1/FAILURE)

Bu yerda eng ko'p ma’lumot beradigan ikki maydon bor:

• Result: — systemd nuqtai nazaridan nosozlikning umumiy toifasi (exit-code, signal, timeout va boshqalar);
• code=/status= — jarayonning aniq chiqish shakli: exited (oddiy chiqish, status= chiqish kodini beradi) yoki killed (signal bilan tugatilgan, status= signal nomini beradi, masalan 9/KILL).

Result: exit-code dasturning o'z mantiqidan emas, systemd jarayonni hatto ishga tushira olmaganidan kelib chiqsa, status= raqami sababni to'g'ridan-to'g'ri nomlaydigan maxsus systemd exec kodi bo'ladi:

Bu to'rttasi "yangi yaratgan unit’im ishga tushmayapti" holatlarining katta qismini ilova log'idan bitta qator ham o'qimasdan hal qiladi — raqam to'g'ridan-to'g'ri aybdor direktivani ko'rsatadi. Oddiy ilova xatosi (Python traceback, noto'g'ri konfiguratsiya qiymati) esa aksincha, dasturning o'z kodi bilan (ko'pincha 1/FAILURE) chiqadi va keyingi qadamda o'qiladi.

Hech kim qo'lda o'ldirmagan, lekin status=9/KILL bilan killed deb ko'rsatilgan jarayon ko'pincha OOM killer ishi bo'ladi. Buni kernel log'ida tasdiqlang:

journalctl -k -b | grep -i -E 'out of memory|killed process'

Yangi systemd versiyalarida holat qatorining o'zida Result: oom-kill yozilishi mumkin va bu taxmin qilish zaruratini yo'qotadi.

2-qadam: to'liq xabarni journalctl bilan o'qish

systemctl status faqat oxirgi bir necha qatorni ko'rsatadi. To'liq kontekst uchun journalctl maqolasida ko'rilgan filtrlashdan foydalaning:

journalctl -u backend-demo.service -n 50 --no-pager

Ko'pincha haqiqiy sabab aynan shu yerda — ilovaning o'z xato xabarida (Python traceback, "Address already in use") yashiringan bo'ladi, systemctl status esa faqat systemd nuqtai nazaridan natijani ko'rsatadi.

3-qadam: bog'liqliklarni tekshirish

Agar unit’ning o'zi joyida ko'rinsa-yu, lekin kutilgan paytda ishga tushmasa yoki kutilmagan tartibda ishlasa, muammo bog'liqlikda bo'lishi mumkin:

systemctl list-dependencies backend-demo.service

backend-demo.service
● ├─network.target
● └─system.slice

Bu buyruq systemd unitlari va targetlari maqolasida ko'rilgan Wants=/Requires= direktivalarining haqiqiy natijasini daraxt ko'rinishida ko'rsatadi — qaysi unit qaysi biriga bog'liqligini ko'z bilan tekshirishning qulay usuli.

Boot vaqtini tahlil qilish: systemd-analyze

Agar muammo aynan boot paytida bo'lsa va biror unit boot vaqtini keragidan ortiq cho'zayotgan bo'lsa, maxsus vosita ishlatiladi.

Umumiy boot vaqti:

systemd-analyze

Startup finished in 2.1s (kernel) + 1.4s (initrd) + 8.7s (userspace) = 12.2s

Qaysi unit eng ko'p vaqt olganini ko'rish:

systemd-analyze blame

5.203s backend-demo.service
1.812s snapd.service
0.421s systemd-udev-settle.service

blame unit’larni har biri o'zi ishga tushishi uchun ketgan vaqt bo'yicha kamayish tartibida ro'yxatlaydi — ro'yxat tepasidagi unit boot’ni sekinlashtirayotgan asosiy nomzod.

Eng uzun ketma-ket bog'liqlik zanjirini ko'rish:

systemd-analyze critical-chain

graphical.target @9.912s
└─multi-user.target @9.910s
  └─backend-demo.service @4.707s +5.203s
    └─network.target @4.703s
      └─network-online.target @4.701s

blame unit’ning o'zi qancha vaqt olganini ko'rsatadi; critical-chain esa target’ga yetish uchun ketma-ket kutilishi kerak bo'lgan unit’larning eng uzun yo'lini ko'rsatadi. Ikkalasi turli savollarga javob beradi, shuning uchun ularni birga ishlatishga arziydi.

Barcha xatolarni bir yo'la ko'rib chiqish

journalctl -p err -b --no-pager

Bu journalctl maqolasidagi -p (priority) filtrini joriy boot bilan birlashtirib, faqat err darajasidagi va undan jiddiyroq yozuvlarni ko'rsatadi. Bir nechta unit bir vaqtda noto'g'ri ishlayotganda barcha muammolarni bir yo'la ko'rish uchun foydali.

Keng tarqalgan xatolar

systemctl status ni yetarli deb hisoblash

status faqat qisqa xulosa beradi. Haqiqiy sabab (masalan, ilova ichidagi to'liq xato matni) ko'pincha faqat journalctl -u <unit> orqali ko'rinadi.

Result: exit-code va Result: signal ni bir xil narsa deb hisoblash

exit-code dasturning o'zi xato bilan tugaganini (masalan, noto'g'ri konfiguratsiya), signal esa uni tashqi kuch (kill, OOM killer) tugatganini bildiradi. Ularning sabablari va yechimlari butunlay boshqacha — birinchisi kodni tekshirishni, ikkinchisi tizim resurslari yoki tashqi ta’sirni tekshirishni talab qiladi.

Bog'liqliklarini tekshirmasdan unit’ni qayta-qayta ishga tushirish

Agar muammo unit’ning o'zida emas, u bog'liq bo'lgan boshqa unit’da bo'lsa (masalan, tarmoq hali tayyor emas), faqat shu bitta unit’ni qayta ishga tushirish vaqtincha yordam berishi mumkin, lekin asl sabab qoladi. systemctl list-dependencies bilan tekshirish bu siklni uzadi.

Mashqlar

1. Sinov VM’ida ataylab ExecStart= yo'li buzilgan (mavjud bo'lmagan faylga ishora qiluvchi) unit yarating, daemon-reload va start ni ishga tushiring, so'ng sababni systemctl --failed va journalctl -u yordamida toping.
2. systemd-analyze blame dagi eng sekin uchta unit’ni qayd qiling va har biri nega shuncha vaqt olayotgan bo'lishi mumkinligini baholang.
3. systemd-analyze critical-chain chiqishini o'qing va graphical.target (yoki multi-user.target) gacha bo'lgan eng uzun ketma-ket yo'lni tasvirlab bering.
4. Ataylab buzilgan unit’ning ExecStart= yo'lini tuzating va u systemctl --failed ro'yxatidan yo'qolganini tasdiqlang.

Mashqni bajardim deyish uchun: ishdan chiqqan unit’ning systemctl status chiqishi berilganda keyingi qadam ilovaning o'z log'ini o'qishmi yoki uning bog'liqliklarini tekshirishmi — buni ayta olishingiz kerak.

Xulosa

systemd nosozligini aniqlash taxmin emas, izchil jarayon: avval systemctl --failed bilan qaysi unit ishdan chiqayotganini aniqlang, so'ng systemctl status bilan natijaning umumiy turini (exit-code yoki signal) tekshiring, keyin journalctl -u bilan to'liq xato matnini o'qing va kerak bo'lsa systemctl list-dependencies bilan bog'liqliklarni tekshiring. Aynan boot vaqti muammolari uchun systemd-analyze blame/critical-chain — maxsus, aniq maqsadli vositalar. Agar muammo shunchalik jiddiy bo'lsaki, tizim umuman boot qilmasa, keyingi maqola — Rescue va emergency mode da ko'riladigan minimal tiklash rejimlari kerak bo'ladi.

Manbalar

• man7.org: systemctl(1)
• man7.org: systemd-analyze(1)
• freedesktop.org: systemd.exec(5) — chiqish holati kodlari
• man7.org: journalctl(1)