Proxmox pvedaemon.service не працює: чому завдання не запускаються і як це виправити

November 25, 2025 • February 3, 2026 • Читання: 7 хв • Views: 8

Було корисно?

Ви натискаєте Start для віртуальної машини. Веб‑інтерфейс робить вигляд, що відправив завдання. Потім нічого не відбувається — немає журналу завдання, немає корисної помилки, лише довга тиша і відчуття, ніби гіпервізор вас судить.
Якщо pvedaemon не працює, Proxmox може виглядати «майже нормально», тоді як єдина річ, яка вам потрібна — виконання завдань — тихо зникає.

Це один з тих збоїв, які крадуть години, бо вони не ламаються голосно. Вони ламаються ввічливо. Ось як швидко діагностувати, правильно виправити і не допустити повернення проблеми, як набридлива регулярна нарада.

Що робить pvedaemon (і чому UI бреше, коли він не працює)

Proxmox — це не моноліт. Це кілька співпрацюючих демонів і веб‑інтерфейс, що здебільшого ретранслює запити до них. Якщо запам’ятати одне:
pvedaemon — це виконавець, який запускає більшість локальних на вузлі завдань — запуск/зупинка гостьових систем, операції зі знімками, резервні копії, дії зі сховищем та багато інших «зробити річ» завдань, які ви запускаєте з UI або API.

Коли pvedaemon не працює, веб‑інтерфейс (pveproxy) може і надалі віддавати сторінки нормально. Аутентифікація працює. Панелі стану відображаються. Ви навіть можете натискати кнопки.
Але коли система намагається створити завдання, вона не може передати його виконавцю. Ось чому ви отримуєте класичну поведінку: UI живий, завдання мертві.

З точки зору надійності: ваша контрольна площина відповідає на HTTP, але виконувача немає. Це як ресторан, який приймає бронювання, поки кухня вогні.

Чого очікувати під час відмови

Записи журналу завдань не з’являються, або з’являються й відразу падають з «connection refused», «timeout» або «no such file».
Резервні копії не запускаються за розкладом або починаються й зависають на блокуваннях.
Запуск ВМ з CLI (qm start) може спрацювати, якщо він обходить частину API‑шляхів, але багато операцій все одно залежать від екосистеми демонів.
У кластері додається ще один рівень складності: завдання можуть відправлятися на невірний вузол або падати через стан кластера, навіть якщо UI виглядає здоровим.

Цитата, яку варто запам’ятати в операціях — приписується Werner Vogels (CTO Amazon): Ти будуєш — ти експлуатуєш. Якщо ви запускаєте Proxmox у продакшені, ви відповідаєте і за цей режим відмови.

Швидкий план діагностики

Не «копирсайтеся». Виконайте чітку послідовність, що звужує область помилки за кілька хвилин. Мета — відповісти на три питання:
Чи справді pvedaemon не працює? Якщо так — чому? І якщо він перезапускається, хто його вбиває?

Перше: підтвердьте стан демона і цикл перезапуску

Перевірте systemctl status pvedaemon і journalctl -u pvedaemon.
Якщо ви бачите «start request repeated too quickly» або коди виходу — це systemd‑сценарій. Виправляйте помилку, а не спамте перезапусками.

Друге: перевірте, чи це не «не pvedaemon, а все під ним»

Переповнений диск на кореневому файловому розділі або /var/log.
Зламаний модуль Perl / некоректне оновлення пакунків.
Проблеми з hostname / DNS / станом кластера, що призводять до помилок API‑викликів.
Тайм‑аути сховища (NFS/iSCSI/Ceph), які блокують завдання і змушують pvedaemon виглядати «завислим».

Третє: визначте підхід до відновлення

Якщо це чистий креш із зрозумілою помилкою в журналі: виправляйте і перезапускайте.
Якщо це зависання через сховище: припиніть «копирсатися» — стабілізуйте спочатку сховище.
Якщо це розподіл кластера: уникайте «випадкових перезапусків». Узгодьте кворум і стан corosync.

Жарт №1 (короткий і по темі): Якщо pvedaemon впав, ваш Proxmox UI перетворюється на дуже дорогий генератор шпалер.

Цікаві факти та контекст (чому це ламається несподівано)

Трохи контексту прискорює усунення неполадок, бо ви перестаєте очікувати від Proxmox поведінки як від одного сервісу.
Ось конкретні факти, що мають значення, коли pvedaemon.service падає:

Завдання Proxmox оркеструються кількома демонами — pveproxy для UI/API, pvedaemon для виконавців і часто pvestatd для оновлення метрик.
Більшість логіки управління Proxmox реалізована на Perl. Відсутній модуль Perl після оновлення може спричинити крах демонів на старті, як підступна ловушка.
systemd обмежує частоту перезапусків і може позначити сервіси як failed, навіть якщо вони могли б відновитися — бо systemd захищає вузол від циклічних аварій.
Proxmox VE розвивався з PVE‑стека з 2008 року з фокусом на Debian‑пакетуванні. Це означає, що стан пакунків має значення: напіввстановлені пакунки можуть паралізувати сервіси.
Журнали завдань пишуться під /var/log/pve/, і повний кореневий розділ може зламати створення завдань так, що це виглядає як «випадкова відмова демона».
Участь у кластері впливає на маршрут завдань. У кластері деякі завдання читають конфіг під /etc/pve, що є розподіленою файловою системою на базі pmxcfs.
/etc/pve — це не «просто директорія». Це спеціальний FUSE‑файловий простір. Якщо pmxcfs має проблеми, конфіги можуть виглядати відсутніми або застарілими, а демони — падати при читанні.
Плагіни сховища можуть блокувати управлінські завдання. Якщо NFS‑сервер зависає, «простий» перелік резервних копій може блокуватися до спаду тайм‑аутів.
Proxmox використовує ідентифікатори завдань (UPID) для відстеження робіт. Якщо ви не можете створити UPID — зазвичай проблема з демоном/журналом/правами, а не «проблема ВМ».

Як проявляються відмови: симптоми, що вказують на pvedaemon

Ви не займаєтеся усуненням неполадок методом здогадок. Підбирайте симптоми до ймовірних доменів проблеми.

Класичні кластери симптомів

Веб‑UI завантажується, але кожна дія падає: запуск ВМ, зупинка, знімок, резервна копія. Це несправність pvedaemon або API‑виконавця, а не QEMU.
Завдання висить як «running» вічно: часто блокування через сховище, конфлікт блокувань або worker, заблокований на I/O.
«Connection refused» або помилки типу «501»: може бути pvedaemon down, проблеми з pveproxy або локальними правами сокета.
Після оновлення завдання перестали працювати: невідповідність пакунків, відсутність залежностей Perl або застарілі сервіси, що не перезапустилися коректно.
У кластері тільки один вузол дивно поводиться: локальна відмова сервісу. Якщо всі вузли дивні — проблема з кворумом/спільним сховищем.

Практичні завдання: команди, очікуваний вивід, і рішення, які ви приймаєте

Нижче — практичні перевірки, які я реально виконую. Кожна містить: команду, що означає її вивід, і яке рішення ухвалити далі.
Використовуйте їх як підручну інструкцію, а не як шведський стіл.

Завдання 1: Перевірити, чи pvedaemon впав, мертвий або в циклі перезапуску

cr0x@server:~$ systemctl status pvedaemon --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2025-12-22 09:14:02 UTC; 2min 11s ago
    Process: 2190 ExecStart=/usr/bin/pvedaemon start (code=exited, status=255/EXCEPTION)
   Main PID: 2190 (code=exited, status=255/EXCEPTION)

Dec 22 09:14:02 server systemd[1]: pvedaemon.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 22 09:14:02 server systemd[1]: pvedaemon.service: Failed with result 'exit-code'.

Значення: Він не працює і вийшов миттєво. Зазвичай це помилка на старті (конфіг, відсутня залежність, права), а не «високе навантаження».

Рішення: Перейдіть одразу в логи (journalctl), щоб знайти першу реальну помилку. Не перезапускайте навмання.

Завдання 2: Читайте журнал pvedaemon, але робіть це серйозно

cr0x@server:~$ journalctl -u pvedaemon -b --no-pager -n 200
Dec 22 09:14:02 server pvedaemon[2190]: Starting pvedaemon
Dec 22 09:14:02 server pvedaemon[2190]: Can't locate PVE/API2/Tasks.pm in @INC (you may need to install the PVE::API2::Tasks module) (@INC contains: /usr/share/perl5 ...)
Dec 22 09:14:02 server pvedaemon[2190]: BEGIN failed--compilation aborted at /usr/bin/pvedaemon line 7.
Dec 22 09:14:02 server systemd[1]: pvedaemon.service: Main process exited, code=exited, status=255/EXCEPTION

Значення: Проблема з пакунками/залежностями. Perl не може знайти модуль Proxmox. Часто трапляється після перерваного оновлення або часткової інсталяції.

Рішення: Перестаньте «лікувати» сервіси — виправляйте пакунки. Перейдіть до Завдання 8 (перевірка стану пакунків).

Завдання 3: Перевірте, чи інші демоні PVE теж нещасні

cr0x@server:~$ systemctl --no-pager --failed
  UNIT                 LOAD   ACTIVE SUB    DESCRIPTION
● pvedaemon.service     loaded failed failed PVE API Daemon
● pvestatd.service      loaded failed failed PVE Status Daemon

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.

Значення: Не тільки один демон. Це вказує на спільні залежності: pmxcfs, бібліотеки Perl, повний диск, зламаний конфіг або невдале оновлення.

Рішення: Розширюйте область перевірки: перевірте pve-cluster/pmxcfs, диск і пакунки, перш ніж ганятися за одним сервісом.

Завдання 4: Підтвердити, що демо веб‑UI не дурить вас

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 08:51:10 UTC; 25min ago
   Main PID: 1422 (pveproxy)
      Tasks: 4 (limit: 154606)
     Memory: 78.3M
        CPU: 6.321s
     CGroup: /system.slice/pveproxy.service
             ├─1422 pveproxy
             └─1427 "pveproxy worker"

Значення: UI/API proxy працює. Користувачі можуть увійти. Вони наполягатимуть, що «Proxmox працює». Вони технічно праві, і це найгірший вид правоти.

Рішення: Зосередьтеся на pvedaemon і бекенд‑ланцюжку (pmxcfs, сховище, пакунки).

Завдання 5: Перевірте pmxcfs і стан кластерної файлової системи (`/etc/pve`)

cr0x@server:~$ systemctl status pve-cluster --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 08:51:07 UTC; 26min ago
   Main PID: 1201 (pmxcfs)
      Tasks: 7 (limit: 154606)
     Memory: 26.9M
        CPU: 2.113s
     CGroup: /system.slice/pve-cluster.service
             └─1201 /usr/bin/pmxcfs -l

cr0x@server:~$ mount | grep /etc/pve
pmxcfs on /etc/pve type fuse.pmxcfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Значення: Якщо pmxcfs не змонтовано або pve-cluster впав, багато конфігів «зникають», і демони можуть падати при їх читанні.

Рішення: Якщо pve-cluster failed — відновіть файлову систему кластера спочатку; перезапуск pvedaemon буде марним.

Завдання 6: Перевірте кворум і corosync (для кластерних вузлів)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod-pve
Config Version:   18
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Mon Dec 22 09:17:12 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2
Quorate:          Yes

Значення: Якщо Quorum — No, кластерна FS може стати лише для читання або застарілою, і управлінські операції можуть падати або поводитися дивно.

Рішення: Якщо немає кворуму — спочатку виправте мережу/corosync. Не «форсувати», якщо ви не готові прийняти ризики split‑brain і точно знаєте, що робите.

Завдання 7: Перевірте вільне місце та виснаження інодів (так, справді)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        94G   94G     0 100% /

cr0x@server:~$ df -ih /var/log
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sda2        6.0M  6.0M     0  100% /

Значення: Повні диски або відсутні іноди можуть завадити запису логів, створенню журналів завдань, тимчасових файлів і навіть роботі сокетів. Демони можуть падати або відмовлятися запускатися.

Рішення: Вивільніть місце негайно (обертання логів, видалення старих локальних бекапів, очищення кешу пакетів). Робіть це перед будь‑яким перезапуском.

Завдання 8: Перевірте стан dpkg/apt (клас помилок «відсутній модуль»)

cr0x@server:~$ dpkg --audit
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure <package> or the configure menu option in dselect:
 pve-manager               Proxmox Virtual Environment management tools

cr0x@server:~$ apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
The following additional packages will be installed:
  pve-cluster pve-container pve-ha-manager
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/5,842 kB of archives.
After this operation, 24.8 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up pve-cluster (8.0.7) ...
Setting up pve-manager (8.2.2) ...

Значення: Напівналаштовані пакунки — яскрава ознака. Якщо відсутні модулі Perl, завдання падатимуть катастрофічно і повторювано.

Рішення: Приведіть стан пакунків до чистого (dpkg --configure -a, apt-get -f install) перед тим, як звинувачувати systemd.

Завдання 9: Спробуйте запустити pvedaemon вручну і стежте за негайними помилками

cr0x@server:~$ systemctl restart pvedaemon
cr0x@server:~$ systemctl status pvedaemon --no-pager
● pvedaemon.service - PVE API Daemon
     Loaded: loaded (/lib/systemd/system/pvedaemon.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 09:20:41 UTC; 3s ago
   Main PID: 3122 (pvedaemon)
      Tasks: 4 (limit: 154606)
     Memory: 64.2M
        CPU: 424ms
     CGroup: /system.slice/pvedaemon.service
             ├─3122 pvedaemon
             └─3123 "pvedaemon worker"

Значення: Сервіс стартував і залишився в активному стані. Це простий випадок.

Рішення: Негайно протестуйте просте завдання (Завдання 12), а потім шукайте первинну причину (повний диск, зламаний пакунок тощо), щоб проблема не повторилася.

Завдання 10: Якщо він продовжує падати, зніміть точну причину виходу

cr0x@server:~$ systemctl show -p ExecMainStatus -p ExecMainCode -p Result pvedaemon
ExecMainCode=1
ExecMainStatus=255
Result=exit-code

Значення: Код виходу 255 поширений для «виключення на старті» у високорівневих рантаймах. Це мало що каже.

Рішення: Потрібне перше виключення в journalctl (Завдання 2) або перевірка пакунків (Завдання 8).

Завдання 11: Перевірте на тиск пам’яті / OOM kills

cr0x@server:~$ journalctl -k -b --no-pager | tail -n 30
Dec 22 09:12:44 server kernel: Out of memory: Killed process 2877 (pvedaemon) total-vm:512004kB, anon-rss:221344kB, file-rss:1232kB, shmem-rss:0kB, UID:0 pgtables:624kB oom_score_adj:0
Dec 22 09:12:44 server kernel: oom_reaper: reaped process 2877 (pvedaemon), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Значення: Ядро вбило процес. Не systemd. Не Proxmox. Ядро. Зазвичай через overcommit пам’яті, некерований гість або виснаження swap.

Рішення: Виправляйте тиск пам’яті: зменшіть overcommit, додавайте swap (обережно), зупиніть проблемні гостьові системи та розгляньте резервування пам’яті для хоста. Перезапуск pvedaemon без усунення пам’яті — це лише петля.

Завдання 12: Перевірте виконання завдання наскрізь

cr0x@server:~$ pvesh get /nodes/$(hostname)/tasks --limit 3
[
  {
    "endtime": 1734868815,
    "id": "UPID:server:00001243:0002A3D1:6767F480:vzdump:101:root@pam:",
    "node": "server",
    "pid": 4675,
    "starttime": 1734868780,
    "status": "OK",
    "type": "vzdump",
    "upid": "UPID:server:00001243:0002A3D1:6767F480:vzdump:101:root@pam:",
    "user": "root@pam"
  }
]

Значення: Завдання створюються, відстежуються і завершуються. Якщо ваш UI все ще поводиться дивно — ймовірна проблема з кешуванням проксі/UI, а не з виконавцем.

Рішення: Якщо це працює, переходьте до перевірки конкретного сховища та того, що спочатку падало (резервні копії, міграції, знімки).

Завдання 13: Знайдіть зависле завдання і з’ясуйте, який worker його тримає

cr0x@server:~$ ls -1 /var/log/pve/tasks | tail -n 5
UPID:server:00000A1C:00006D32:6767F1C0:qmstart:103:root@pam:
UPID:server:00000A21:00006DA0:6767F1E2:vzsnapshot:101:root@pam:
UPID:server:00000B10:00008211:6767F23A:vzdump:101:root@pam:
UPID:server:00000B15:00008260:6767F248:qmstop:102:root@pam:
UPID:server:00000B19:00008288:6767F251:qmstart:104:root@pam:

cr0x@server:~$ tail -n 50 "/var/log/pve/tasks/UPID:server:00000B10:00008211:6767F23A:vzdump:101:root@pam:"
INFO: starting new backup job: vzdump 101 --storage backup-nfs --mode snapshot --compress zstd
ERROR: storage 'backup-nfs' is not online
INFO: backup job failed

Значення: Це не «pvedaemon впав». Це «завдання виконалося й впало». Журнал каже, який підсистемі треба приділити увагу.

Рішення: Перестаньте дебажити демони. Виправляйте підключення/стан сховища.

Завдання 14: Перевірте блокування, що затримують завдання (поширено при проблемах зі сховищем)

cr0x@server:~$ pvesh get /cluster/locks
[
  {
    "lock": "backup",
    "node": "server",
    "type": "storage",
    "id": "backup-nfs",
    "time": 1734868001
  }
]

Значення: Існує блокування. Блокування — це не погано; це механізм послідовності. Але можуть виникати застарілі блокування після краху або тайм‑аутів.

Рішення: Якщо блокування старе і завдання мертве — переконайтеся, що активний процес не працює, потім безпечно очистіть його (див. Завдання 15). Не видаляйте файли блокувань навмання.

Завдання 15: Підтвердіть, чи операція «зависла», перед тим як щось чистити

cr0x@server:~$ ps aux | egrep 'vzdump|qemu-img|pvesm|pvedaemon' | grep -v egrep
root      3122  0.0  0.2  52440 18944 ?        Ss   09:20   0:00 pvedaemon
root      4675  0.1  0.3 120332 26420 ?        Ss   09:24   0:02 vzdump 101 --storage backup-nfs --mode snapshot --compress zstd

Значення: Робота все ще виконується. Очищення блокувань зараз — чудовий спосіб створити перекривні резервні копії і неконсистентні знімки.

Рішення: Якщо вона зависла — дебагуйте чому (зазвичай I/O сховища). Вбивайте процес лише якщо розумієте наслідки (очищення знімків, неповні архіви).

Завдання 16: Підтвердьте стан сховища як бачить його Proxmox (не так, як ви бажаєте)

cr0x@server:~$ pvesm status
Name         Type     Status     Total     Used     Available  %
local        dir      active     93.00G   12.40G     75.85G   13%
backup-nfs   nfs      inactive       0B       0B         0B    0%

Значення: Сховище неактивне. Якщо завдання залежать від нього — вони впадуть або зависнуть.

Рішення: Розбирайтеся зі сховищем на рівні ОС: монтування, мережа, облікові дані. Не звинувачуйте pvedaemon за відмову використовувати офлайн‑сховище.

Завдання 17: Перевірте NFS‑монти і відгук (приклад)

cr0x@server:~$ grep backup-nfs /etc/pve/storage.cfg
nfs: backup-nfs
        server 10.20.30.40
        export /srv/nfs/pve-backup
        path /mnt/pve/backup-nfs
        content backup
        options vers=4.1,proto=tcp

cr0x@server:~$ mount | grep /mnt/pve/backup-nfs || echo "not mounted"
not mounted

cr0x@server:~$ timeout 5 bash -lc 'ls -la /mnt/pve/backup-nfs'
ls: cannot access '/mnt/pve/backup-nfs': No such file or directory

Значення: Шлях сховища не існує або не змонтований. Proxmox позначає його як offline, завдання падають. Якщо шлях існує, але ls зависає — інша проблема: завислий NFS‑монт.

Рішення: Виправте визначення монтування/шлях, а якщо монти зависають — використовуйте umount -f або лениве відмонтування обережно. Не перезавантажуйте вузол, щоб полагодити монт, якщо ви не любите простій.

Завдання 18: Перевірте проблеми з TLS/невідповідністю hostname (тонкий убивця завдань)

cr0x@server:~$ hostname -f
server.example.internal
cr0x@server:~$ grep -E 'server|127.0.1.1' /etc/hosts
127.0.0.1 localhost
127.0.1.1 server.example.internal server

Значення: Розв’язування імен узгоджене. Якщо ні — якщо hostname -f повертає щось, що не відповідає сертифікатам або конфігу кластера — ви можете бачити дивні API‑помилки і плутанину у демонах.

Рішення: Виправте hostname/DNS/hosts узгоджено по всьому кластеру. Не додавайте ще один запис у hosts без розуміння; так створюють привиди інфраструктури.

Реальні причини, що трапляються в продакшені

1) Зламаний стан пакунків після оновлення (найпоширеніший)

Оновлення Proxmox зазвичай проходять гладко — поки ні. Режим відмови не завжди «оновлення провалилося». Іноді оновлення «майже спрацювало» і лишає відсутні модулі Perl, напівналаштовані пакунки або демони, що працюють зі старим кодом проти нових бібліотек.

Ознака: Can't locate ... in @INC, BEGIN failed, або скарги dpkg. Виправляйте це завершенням конфігурації пакунків і перевіркою репозиторіїв, сумісних з вашими версіями Proxmox/Debian.

2) Повний диск або виснаження інодів (тихо летально)

Proxmox пише журнали завдань, стан і тимчасові дані. Якщо root переповнений — симптом часто «завдання не запускаються» або «сервіс не залишається запущеним».
Люди люблять ігнорувати алерти про диск, поки вони не стануть обов’язковими.

Часті тригери: локальні резервні копії на сховищі local, некеровані журнали, дампи краху або збір ISO.

3) Проблеми pmxcfs або стану кластера

У кластері /etc/pve — це запас конфігів. Якщо він недоступний, демони, які читають конфіг, можуть падати або поводитися некоректно.
Якщо кворум втрачається, ви можете спостерігати застарілі читання або заблоковані записи. Це не крихкість Proxmox — це відмова Proxmox брехати про розподілений стан.

4) Тайм‑аути сховища і завислий I/O (pvedaemon «вверх», але марний)

Ви можете мати працюючий pvedaemon, який фактично мертвий, бо його worker’и блоковані на I/O. Це особливо часто трапляється з:

NFS‑монти, що зависають замість швидкого падіння
Неправильна конфігурація iSCSI multipath
Проблеми здоров’я Ceph (повільні операції, заблоковані запити)
Коливання шляхів Fibre Channel, що спричиняють довгі SCSI тайм‑аути

Трюк — відрізнити: демон впав чи демон заблокований. Логи і стан процесів підкажуть.

5) Тиск пам’яті та OOM kills

Коли ядро починає вбивати процеси, воно не обирає те, що вам подобається. Якщо pvedaemon потрапляє під удар — завдання зупиняються. Але справжня проблема — управління пам’яттю хоста: ballooning, політика swap і те, що «воно завантажилося» не означає «воно стабільне».

6) Права й особливості файлової системи (контейнери ускладнюють)

Проблеми з правами з’являються, коли журнали завдань не можуть бути записані, коли директорія під /var/lib має неправильного власника, або коли хтось «затвердив» вузол і порушив припущення.
Proxmox не боїться харденігу, але очікує базових речей: правильних власників, записуваних шляхів і розумних опцій монтування.

Три корпоративні міні‑історії (бо це завжди трапляється з «комусь іншому»)

Міні‑історія 1: Інцидент через неправильне припущення

Середня компанія мала двовузловий кластер Proxmox для «високої доступності». Не HA‑manager, просто кластер. Їхнє припущення: «Два вузли означають резервування».
Команда мереж зробила рутинну зміну на ядрі комутатора. Через короткий широкомовний шторм corosync почав скидати пакети.

Вузол A все ще віддавав веб‑UI. Люди увійшли і спробували перезапустити кілька «завислих» ВМ. Завдання не запускалися. Звісно, хтось вирішив: «pvedaemon зламався».
Вони перезапускали демони. Вони перезавантажили весь вузол. Нічого не покращилося, бо вузол був без кворуму і pmxcfs відмовився поводитися як одно вузлова FS.

Неправильне припущення було не про pvedaemon. Воно було про кворум. Двовузлові кластери — це технічний борг, якщо не спроектувати кворум (witness, qdevice або третій вузол).

Виправлення не було героїчним: відновили corosync‑з’єднання, відновили кворум, підтвердили здоров’я /etc/pve, потім акуратно перезапустили сервіси.
Після цього вони додали пристрій кворуму. Нудно. Ефективно. Єдиний вид «резервування», що має значення о 3‑й ранку.

Міні‑історія 2: Оптимізація, що зіграла злий жарт

Інший магазин хотів пришвидшити резервні копії. Вони переключили vzdump на NFS з агресивними опціями монтування і тонко налаштованими тайм‑аутами, бо «дефолти повільні».
Це працювало. Деякий час. Резервні копії були швидшими, коли NAS був здоровий.

Потім у NAS стався failover контролера під час вікна бекапів. NFS‑експорт не впав чисто; він став «напівживим». Читання іноді працювали. Метадані зависали.
З точки зору Proxmox, завдання запускалися й потім заморожувалися. Worker’и накопичувалися. pvedaemon залишався працюючим, але черги завдань стали паркувальною зоною.

«Оптимізація» створила систему, що відмовляла шляхом зависання, а не швидкого падіння. Це найгірший режим відмови для runner‑а завдань, бо він їсть ресурси worker’ів, не даючи корисної помилки.

Довгострокове виправлення: перестати вважати сховище магічною чорною скринькою — додали моніторинг відгуку NFS (не тільки ping), змінили поведінку монтування на користь швидкого падіння і рознесли резервні копії в часі, щоб зменшити радіус ураження.
Резервні копії стали трохи повільніші. Інциденти — значно рідші. Більшість дорослих погодяться на такий компроміс.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Регульоване середовище запускало кластери Proxmox з суворим процедурним набором: перед оновленнями перевіряли вільне місце на root, підтверджували стан dpkg і робили бекап конфігів /etc/pve (плюс нотатку з поточними версіями).
Ніхто не любив цей чеклист. Це була паперова робота з shell‑командами.

Під час одного вікна оновлення дзеркало почало валитися і залишило pve-manager напівналаштованим. pvedaemon не стартував, і завдання згасли.
Інженер на чергуванні не імпровізував. Він виконав нудний план: перевірив стан пакунків, виправив залежності, повторив налаштування і в певному порядку перезапустив демони.

Оскільки у них був відомий добрий базис (версії, місце і копія конфігів), вони могли приймати впевнені рішення швидко. Без здогадок. Без «можливо це DNS» істерик.
Система швидко відновилася, а постінцидентний звіт був коротким — тихий знак професійного щастя.

Жарт №2 (короткий і по темі): Єдина річ більш наполеглива ніж старе блокування — це керівник, що питає, чи ви «спробували перезапустити».

Типові помилки: симптом → корінна причина → виправлення

Цей розділ різкий навмисно. Це помилки, які перетворюють 10‑хвилинне виправлення на південно‑денну пригоду.

1) «Завдання не запускаються, тож я перезавантажую весь вузол»

Симптом: UI працює; завдання ніколи не стартують або відразу падають.
Корінна причина: pvedaemon впав через відсутні пакунки або повний диск; reboot цього не виправить.
Виправлення: Перевірте systemctl status pvedaemon, потім journalctl -u pvedaemon, а потім виправляйте пакунки/диск перед перезапуском.

2) «Я очистив блокування, бо все виглядало завислим»

Симптом: Бекапи/міграції зависають; у кластерних блокуваннях видно записи.
Корінна причина: Робота все ще працює, але заблокована на сховищі; очищення блокування спричинить перекривні операції.
Виправлення: Підтвердіть процеси через ps і відгук сховища. Очищайте блокування лише коли доведено, що worker помер.

3) «Сховище в порядку, бо ping відповідає»

Симптом: pvedaemon працює, але завдання зависають, особливо бекапи/знімки.
Корінна причина: NFS/iSCSI/Ceph стопоряться на рівні I/O; ping — не релевантний.
Виправлення: Тестуйте реальні операції: ls на монтуванні, чит/запис невеликих файлів, перевірте pvesm status, перегляньте kernel‑логи на тайм‑аути I/O.

4) «Я оновив, воно завершилось, тож пакунки мають бути в порядку»

Симптом: pvedaemon виходить з помилками модуля Perl.
Корінна причина: Напівналаштовані пакунки або неправильні репозиторії.
Виправлення: dpkg --audit, dpkg --configure -a, apt-get -f install, потім перезапуск сервісів.

5) «Це одновузлове рішення, кластерні сервіси не важливі»

Симптом: Зчитування конфігів не вдаються, /etc/pve виглядає неправильно, завдання помиляються при доступі до конфігів.
Корінна причина: pmxcfs/pve-cluster впав навіть на «одновузловій» установці, бо Proxmox все одно використовує його для управління конфігом.
Виправлення: Відновіть здоров’я pve-cluster і підтвердьте, що /etc/pve змонтовано як fuse.pmxcfs.

6) «Я полагодив демон, але завдання все одно не працюють»

Симптом: pvedaemon active; дії через UI все ще помиляться або зависають.
Корінна причина: Підлягаюче сховище офлайн, застаріле блокування або маршрутизація API/невідповідність hostname.
Виправлення: Перевірте журнали завдань у /var/log/pve/tasks/, стан pvesm status і підтвердьте узгодженість hostname/DNS.

Контрольні списки / покроковий план

Контрольний список A: Швидке відновлення виконання завдань (одновузлово)

Перевірте місце і іноди: df -h /, df -ih /. Звільніть при потребі.
Перевірте статус сервісів: systemctl status pvedaemon.
Перевірте логи: journalctl -u pvedaemon -b -n 200. Знайдіть першу реальну помилку.
Якщо пакунки: запустіть dpkg --audit, потім dpkg --configure -a, потім apt-get -f install.
Підтвердьте pmxcfs: systemctl status pve-cluster і mount | grep /etc/pve.
Перезапускайте в розумному порядку:
- systemctl restart pve-cluster (якщо потрібно)
- systemctl restart pvedaemon
- systemctl restart pveproxy (опціонально, якщо UI поводиться дивно)
Підтвердіть через pvesh get /nodes/$(hostname)/tasks --limit 3 і запустіть одне тестове завдання (start/stop тестової ВМ).

Контрольний список B: Відновлення з урахуванням кластера (не погіршуйте ситуацію)

Спочатку перевірте кворум: pvecm status.
Якщо немає кворуму: виправляйте corosync‑мережу спочатку. Уникайте випадкових перезапусків.
Підтвердьте, що /etc/pve змонтовано і узгоджено на вузлі, з якого працюєте.
Перевірте логи pvedaemon на помилки читання конфігів або прав.
Перевірте стан сховища з вузла, де падають завдання: pvesm status.
Лише після вищевказаного: перезапустіть pvedaemon на ураженому вузлі та протестуйте завдання.

Контрольний список C: Запобігання повторенню (те, що більшість команд пропускає)

Налаштуйте оповіщення про вільне місце на root‑файловій системі там, де люди їх бачать, і реагуйте.
Після оновлень перевіряйте стан демонів: systemctl is-active pvedaemon і запускайте одне тестове завдання.
Робіть сховище «впадати швидко» там, де можливо, і моніторьте відгук сховища (не тільки досяжність).
Документуйте, як ваш кластер поводиться з кворумом (особливо якщо це два вузли).
Тримайте план відкату для пакунків: кеші пакунків, локальні mirror’и або хоча б протестовану процедуру відновлення.

Часті запитання

1) Що саме ламається, коли pvedaemon не працює?

Більшість локальних на вузлі управлінських завдань: життєвий цикл VM/LXC, резервні копії, знімки, багато операцій зі сховищем і все, що потребує worker’a і відстеження UPID.

2) Чому веб‑UI все ще завантажується, якщо pvedaemon впав?

Бо pveproxy обслуговує UI і API фронтенд. Він може відповідати навіть якщо бекенд‑виконавець відсутній. UI не злий; він просто оптимістичний.

3) Як відрізнити «pvedaemon впав» від «pvedaemon завис»?

Якщо systemd показує failed або inactive — він впав або не стартував. Якщо active (running), але завдання зависають — перевіряйте I/O сховища, блокування і стан worker‑процесів.

4) Я бачу «Can’t locate … in @INC» в журналі. Що далі?

Виправляйте стан пакунків. Запустіть dpkg --audit, потім dpkg --configure -a і apt-get -f install. Це майже ніколи не вирішується правкою випадкових Perl‑шляхів.

5) Чи можу я просто перевстановити pve-manager?

Іноді так, але ставтеся до цього як до проблеми стану пакунків, а не одного пакунка. Примусова перевстановлення без вирішення невідповідності репозиторіїв або часткових оновлень може погіршити ситуацію.

6) Завдання застопорені і я бачу блокування. Чи безпечно їх видаляти?

Лише після підтвердження, що підлягаючий процес не працює і підсистема сховища стабільна. Блокування існують, щоб запобігти пошкодженню; їх сліпе очищення — гра з вашими даними.

7) Чи можуть DNS/hostname‑проблеми реально спричинити відмови завдань?

Так, особливо в кластерах, де вузли посилаються один на одного за іменами і перевіряють сертифікати. Невідповідність розв’язування імен може спричинити помилки API, міграцій і робіт зі сховищем, що виглядають несумісними.

8) Чи допоможе перезапуск pveproxy, коли завдання не запускаються?

Рідко. Якщо pvedaemon мертвий, перезапуск UI‑proxy — це театр. Перезапустіть pvedaemon після виправлення причини, і лише потім перезапускайте pveproxy, якщо UI кешує помилки або поводиться дивно.

9) Чи пов’язано це саме з vzdump‑резервними копіями?

Резервні копії часто запускають проблему, бо сильно навантажують сховище і створюють блокування. Але падіння pvedaemon ширше: будь‑яке збоєве місце виконавця завдань вплине на багато операцій.

10) Який найшвидший тест «виправлено чи ні?»

Запустіть нешкідливе, швидке завдання і підтвердіть його завершення. Наприклад, подивіться останні завдання через pvesh і виконайте stop/start на некритичній ВМ.
Якщо завдання генерують UPID і завершаються — шлях виконавця відновлено.

Висновок: наступні кроки, що працюють

Коли pvedaemon.service падає, Proxmox не стільки «впадає», скільки перестає виконувати роботу. Саме тому це їсть час: панелі все ще відображаються, користувачі натискають, і нічого фактично не відбувається.

Зробіть це далі, у такому порядку:

Підтвердіть режим відмови: впав чи завис (systemctl status, journalctl).
Виправте звичні підозрювані: диск/іноди, стан пакунків, pmxcfs/kворум, відгук сховища.
Перезапускайте обдумано: перезапустіть потрібні демони в правильному порядку, потім проведіть тест завдання наскрізь.
Запобігайте поверненню: налаштуйте оповіщення про вільне місце, перевіряйте після оновлень і моніторьте сховище як частину обчислювальної інфраструктури — бо воно є такою.

Схожі статті

Proxmox — «Connection refused» на 8006 після оновлень: що перевірити в першу чергу