+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

System Hang at 'Reached target Reboot', Proxmox Виртуальная Среда

upnort

Guest

02.05.2019 21:49:00

Proxmox 5.4, полностью обновлённый, ядро: 4.15.18-12. Мы не используем OOB или кластеризацию. Вывод pveversion ниже. У нас есть система Proxmox, которая при каждом втором перезагрузке зависает на сообщении "Достигнута цель перезагрузки" в stdout. Если оставить без внимания, при полном зависании система в конечном итоге перезагрузится через примерно 30 минут. Журналы системы подтверждают 30 минут. Это время вряд ли кажется случайным — как будто задано где-то в коде. Причина задержки пока не известна. Поиск в интернете находит множество аналогичных отчётов и указывает на две возможные общие причины. Одна — зависание клиента NFS, другая — нехватка размонтирования swap-раздела. Вчера я локально перезагрузил сервер после обновлений. Перед тем как начать перезагрузку, я открыл консоль отладки (systemctl start debug-shell). Система снова, казалось, зависла на 'Достигнута цель перезагрузки'. Я переключился на консоль отладки и обнаружил, что swap еще не размонтирован. Не знаю, нормально ли это. У меня едва хватило времени на дальнейшее исследование, потому что в этот момент система продолжила перезагрузку. На этот раз система не зависла на полных 30 минут, но я также не смог собрать или просмотреть какие-либо значимые данные. Не могу с уверенностью сказать, что задержка в несколько секунд вчера — это нормально. Как и многие серверы виртуальных машин, мы не перезагружаемся часто. Сбор данных — это задача. Не разрешив эту задержку, мы не можем перезагрузить эту систему удалённо. Есть идеи о причине этой задержки? Большое спасибо. pveversion -v: Код: proxmox-ve: 5.4-1 (работающее ядро: 4.15.18-12-pve) pve-manager: 5.4-3 (работающая версия: 5.4-3/0a6eaa62) pve-kernel-4.15: 5.3-3 pve-kernel-4.15.18-12-pve: 4.15.18-35 pve-kernel-4.15.18-11-pve: 4.15.18-34 corosync: 2.4.4-pve1 criu: 2.11.1-1~bpo90 glusterfs-client: 3.8.8-1 ksm-control-daemon: 1.2-2 libjs-extjs: 6.0.1-2 libpve-access-control: 5.1-8 libpve-apiclient-perl: 2.0-5 libpve-common-perl: 5.0-50 libpve-guest-common-perl: 2.0-20 libpve-http-server-perl: 2.0-13 libpve-storage-perl: 5.0-41 libqb0: 1.0.3-1~bpo9 lvm2: 2.02.168-pve6 lxc-pve: 3.1.0-3 lxcfs: 3.0.3-pve1 novnc-pve: 1.0.0-3 proxmox-widget-toolkit: 1.0-25 pve-cluster: 5.0-36 pve-container: 2.0-37 pve-docs: 5.4-2 pve-edk2-firmware: 1.20190312-1 pve-firewall: 3.0-19 pve-firmware: 2.0-6 pve-ha-manager: 2.0-9 pve-i18n: 1.1-4 pve-libspice-server1: 0.14.1-2 pve-qemu-kvm: 2.12.1-3 pve-xtermjs: 3.12.0-1 qemu-server: 5.0-50 smartmontools: 6.5+svn4324-1 spiceterm: 3.0-5 vncterm: 1.5-3 zfsutils-linux: 0.7.13-pve1~bpo2

upnort

Guest

22.08.2019 20:22:00

Просто для справки, этот сбой перезагрузки снова произошел на этом же сервере. В логах никаких подсказок. Снова, через 30 минут система наконец перезагрузилась. Подозреваю, что эти 30 минут – это тайм-аут systemd. У нас есть несколько предустановленных NFS-монтов в storage.cfg, но они отключены. Монты предустановлены для использования в случае восстановления после сбоя, чтобы иметь возможность восстановить файлы с резервных серверов. Поскольку активных NFS-монтов нет, это, похоже, указывает на то, что swap не был правильно отключен. Отладка этого – настоящая проблема, потому что система зависает только периодически. До сих пор при локальной перезагрузке сервер еще не зависал. Когда система зависает при удаленной перезагрузке, время ожидания превышает 30 минут, так что попытки использовать альтернативный отладочный шелл бесполезны.

Stoiko Ivanov

Guest

23.08.2019 15:22:00

* Вы могли бы попробовать настроить syslog на удаленный сервер (или удаленное журналирование). * Убедитесь, что у вас включено постоянное журналирование. * Если сервер находится в удаленном месте, есть ли у него какой-то способ управления вне канала? (IPMI, iDrac, iKVM, что-то, что предлагает ваш интернет-провайдер/хостинг, или кто-то, кто работает в удаленном месте с камерой?) - тогда вы могли бы использовать это для получения каких-либо данных. * Если у вас есть вторая машина в этом месте, настройка последовательной консоли с перекрестным кабелем также может дать некоторое понимание. Надеюсь, это поможет!

mailinglists

Guest

23.08.2019 15:56:00

Привет! Просто к сведению, я столкнулся с аналогичной проблемой с PM 5 после полного обновления около месяца или двух назад. Я перезагрузил его удаленно, но он не включился. Мне пришлось поехать в офис (1 час ночи - такая жизнь системных администраторов

). Как только я открыл дверь офиса, примерно через 30 минут, система мониторинга прислала мне СМС, что все заработало. Логи ничего не показали. Ещё одна перезагрузка ничего не дала, и она была быстрой, как ожидалось. С тех пор не обновлял его. Буду следить за этой темой, чтобы узнать, что вы выяснили.

mailinglists Guest	#5 0 10.09.2019 07:54:00 Я только что испытал то же самое с тем же оборудованием Supermicro на базе AMD, но на другом сервере. Возвращение заняло ровно 30 минут. Я не смог вовремя получить доступ к IPMI или подключить экран.

mailinglists

Guest

10.09.2019 07:58:00

Логи ничего интересного не показывают: Код: 10 сент. 06:27:45 lic2 systemd[1]: Остановлен PVE API Proxy Server. 10 сент. 06:27:45 lic2 systemd[1]: Остановка сервера OpenBSD Secure Shell... 10 сент. 06:27:45 lic2 systemd[1]: Остановлена цель PVE Storage Target. 10 сент. 06:27:45 lic2 systemd[1]: Остановлен сервер OpenBSD Secure Shell. 10 сент. 06:27:45 lic2 systemd[1]: Остановлен демон управления ресурсами кластера PVE. 10 сент. 06:27:45 lic2 systemd[1]: Остановка демона PVE API... 10 сент. 07:00:20 lic2 systemd-modules-load[1430]: Вставлен модуль 'iscsi_tcp' 10 сент. 07:00:20 lic2 kernel: [ 0.000000] Версия Linux 4.15.18-20-pve (root@nora) (gcc версия 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP PVE 4.15.18-46 (Чт, 8 авг 2019 10:42:0 10 сент. 07:00:20 lic2 systemd-modules-load[1430]: Вставлен модуль 'ib_iser' 10 сент. 07:00:20 lic2 kernel: [ 0.000000] Командная строка: BOOT_IMAGE=/ROOT/pve-1@/boot/vmlinuz-4.15.18-20-pve root=ZFS=rpool/ROOT/pve-1 ro root=ZFS=rpool/ROOT/pve-1 boot=zfs quiet 10 сент. 07:00:20 lic2 kernel: [ 0.000000] Поддерживаемые процессоры ядра: 10 сент. 07:00:20 lic2 kernel: [ 0.000000] Intel GenuineIntel 10 сент. 07:00:20 lic2 kernel: [ 0.000000] AMD AuthenticAMD 10 сент. 07:00:20 lic2 systemd-modules-load[1430]: Вставлен модуль 'vhost_net'

mailinglists Guest	#7 0 10.09.2019 08:15:00 Для вашего сведения, я заметил, что на всех этих серверах, где мы столкнулись с временем перезагрузки в 30 минут, IPMI тоже перестал работать.

Stoiko Ivanov

Guest

10.09.2019 10:50:00

Это может указывать на то, что проблема не связана с установленной системой - IPMI должен работать, пока коробка под напряжением? IPMI находится на выделенном интерфейсе или разделен с хостом? В противном случае логи могут не отображать всей информации - если хост падает при завершении работы, последние минуты могут не сохраниться на диске. Надеюсь, это поможет!

mailinglists

Guest

17.09.2019 14:15:00

Я согласен, именно поэтому я это и упомянул. Система, возможно, ждала IMPI, который не запустился, и продолжила загрузку Linux после определенного времени ожидания. IPMI подключен к выделенному сетевому интерфейсу. Логи показывают аккуратное завершение работы с точки зрения Linux.

Stoiko Ivanov

Guest

#10

17.09.2019 14:37:00

Хмм, похоже, что в логах не хватает довольно многих строк (сравнивая с моим журналом во время корректного завершения работы — обычно после pvedaemon (Stopping PVE API Daemon...) останавливается много служб, например, все смонтированные файловые системы размонтируются, сеть отключается... последние строки для корректного завершения работы на моем системе выглядят так: Код: 13 сент. 21:10:45 узел systemd[1]: Завершение работы. 13 сент. 21:10:45 узел kernel: printk: systemd-shutdown: 1 строка вывода подавлена из-за ограничения скорости 13 сент. 21:10:45 узел systemd-shutdown[1]: Синхронизация файловых систем и блочных устройств. 13 сент. 21:10:45 узел systemd-shutdown[1]: Отправка SIGTERM оставшимся процессам... 13 сент. 21:10:45 узел systemd-journald[6435]: Журнал остановлен. Лог IPMI показывает что-то интересное?

mailinglists

Guest

#11

17.09.2019 15:14:00

О, есть... хорошо, я это не заметил. Спасибо, что указал. Возможно, тогда были какие-то зависшие процессы, и systemd наконец решил перезагрузить сервер через 30 минут. IPMI полностью перестал работать, я не могу к нему получить доступ. Я не могу перезагрузить эти серверы просто ради теста, так что мы, по сути, застряли с этой проблемой. Все, что я знаю, это то, что при следующем запланированном обновлении с перезагрузкой мне, возможно, придется подождать 30 минут. Я могу прийти в центр, чтобы сделать это и понаблюдать за экраном. К счастью, в работе остались только два таких сервера, и один скоро заменят. Также спасибо, что нашел время помочь, Стойко. Но эта проблема для меня уже не столь актуальна.

upnort Guest	#12 0 17.10.2019 22:13:00 Ещё информация: что касается моего первоначального сообщения, причиной является неразмонтированный swap. Сегодня сервер не смог перезагрузиться вовремя. Я включил отладочный консоль и подтвердил, что раздел swap остался смонтированным. В логах никаких подсказок. Снова, обычный раздел swap, ZFS не используется. Перед перезагрузкой я вручную выключил (pct shutdown, qm shutdown) все гостевые системы. В отладочной консоли мне удалось выполнить swapoff -a. Это заняло некоторое время, но после размонтирования swap система завершила первоначальную перезагрузку. К сожалению, я не углубился в возможные первопричины. Следующий шаг — выяснить, почему именно на этой системе раздел swap иногда не размонтируется. Симптомы с swap были зафиксированы несколько лет назад. Есть и другие случайные сообщения в интернете. Полагаю, зависание связано с редкостью перезагрузок — чем дольше период между перезагрузками, тем выше вероятность зависания. У нас недостаточно данных, чтобы определить, что считается «долгим», но если между перезагрузками проходит продолжительное время, я предполагаю, что swap на самом деле используется для размещения памяти, и сигнал перезагрузки не очищает swap, есть процесс или файл, который удерживает swap в использовании, или не все процессы завершаются, оставаясь в использовании swap. Загадка состоит в том, почему только эта система?

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры