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

RSS

LXC теряет сетевой интерфейс через несколько дней — возможное решение найдено, но почему так происходит?, Proxmox Виртуальная Среда

virtManager

Guest

05.06.2022 13:42:00

Привет! Я поставил Turnkey-fileserver (LXC) для создания SMB/CIFS и NFS-шар с низким потреблением ресурсов и быстрой дисковой производительностью, чтобы не создавать отдельную виртуалку (да и потому что читал, что ставить такое прямо на хост — плохая идея). Проблема в том, что спустя пару дней я обычно не могу пропинговать сетевой интерфейс, остается только loop-back устройство:

Код:
root@turnkey-fileserver ~# ip -4 a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever

Ошибка, которую вижу при проверке статуса сети:

Код:
root@turnkey-fileserver ~# systemctl status networking
* networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2022-05-28 20:14:42 CEST; 2 days ago
Docs: man:interfaces(5)
Process: 77 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
Main PID: 77 (code=exited, status=1/FAILURE)
CPU: 118ms

May 28 20:14:32 turnkey-fileserver ifup[77]: udhcpc: sending discover
May 28 20:14:35 turnkey-fileserver ifup[77]: udhcpc: sending discover
May 28 20:14:38 turnkey-fileserver ifup[77]: udhcpc: sending discover
May 28 20:14:42 turnkey-fileserver ifup[77]: /etc/udhcpc/default.script: Lease failed:
May 28 20:14:42 turnkey-fileserver ifup[77]: udhcpc: no lease, failing
May 28 20:14:42 turnkey-fileserver ifup[77]: ifup: failed to bring up eth0
May 28 20:14:42 turnkey-fileserver systemd[1]: networking.service: Main process exited, code=exited, sta
May 28 20:14:42 turnkey-fileserver systemd[1]: networking.service: Failed with result 'exit-code'.
May 28 20:14:42 turnkey-fileserver systemd[1]: Failed to start Raise network interfaces.
May 28 20:14:42 turnkey-fileserver systemd[1]: networking.service: Consumed 118ms CPU time.

Я пытался искать похожие случаи и нашёл вот это: https://forum.proxmox.com/threads/lxc-lose-sometimes-network-connection.68686/ с ответом: «Думаю, DHCP-аренда больше не обновляется. Я бы поставил статический IP.» — но нет. У меня используется pfSense (виртуализирован на сервере Proxmox), и все остальные устройства получают обновление DHCP-аренды без проблем. Так что, по-моему, проблема не в DHCP-сервере...

Я могу (хоть и неудобно, приходится заходить в LXC вручную, а это не должно быть нужно регулярно, сеть должна всегда работать, как у остальных устройств) поднять сеть командой:

Код:
root@turnkey-fileserver ~# systemctl restart networking
root@turnkey-fileserver ~# systemctl status networking
* networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Active: active (exited) since Mon 2022-05-30 22:09:23 CEST; 5s ago
Docs: man:interfaces(5)
Process: 2646 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=0/SUCCESS)
Main PID: 2646 (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 17848)
Memory: 340.0K
CPU: 256ms
CGroup: /system.slice/networking.service
`-2684 /sbin/udhcpc -n -p /run/udhcpc.eth0.pid -i eth0

May 30 22:09:23 turnkey-fileserver systemd[1]: Starting Raise network interfaces...
May 30 22:09:23 turnkey-fileserver ifup[2646]: udhcpc: started, v1.30.1
May 30 22:09:23 turnkey-fileserver ifup[2646]: udhcpc: sending discover
May 30 22:09:23 turnkey-fileserver ifup[2646]: udhcpc: sending select for 192.168.100.10
May 30 22:09:23 turnkey-fileserver ifup[2646]: udhcpc: lease of 192.168.100.10 obtained, lease time 7200
May 30 22:09:23 turnkey-fileserver ifup[2646]: /etc/udhcpc/default.script: Resetting default routes
May 30 22:09:23 turnkey-fileserver ifup[2646]: SIOCDELRT: No such process
May 30 22:09:23 turnkey-fileserver ifup[2646]: /etc/udhcpc/default.script: Adding DNS 192.168.100.1
May 30 22:09:23 turnkey-fileserver ifup[2646]: /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf
May 30 22:09:23 turnkey-fileserver systemd[1]: Started Raise network interfaces.

root@turnkey-fileserver ~# ip -4 a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link-netnsid 0
inet 192.168.100.10/24 brd 192.168.100.255 scope global eth0
valid_lft forever preferred_lft forever

Ещё нашёл эту ветку и ответ: https://askubuntu.com/a/1026911, где советуют изменить в файле /etc/network/interfaces строку «auto eth0» на «allow-hotplug eth0» (с последующей строкой «iface eth0 inet dhcp»). Это действительно помогло стабилизировать сеть!

Расскажу подробнее, потому что это, собственно, мой вопрос (выше — просто контекст):

БЫЛО — /etc/network/interfaces (на LXC fileserver):
Код:
# UNCONFIGURED INTERFACES
# remove the above line if you edit this file

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

СТАЛО — /etc/network/interfaces (на LXC fileserver):
Код:
# UNCONFIGURED INTERFACES
# remove the above line if you edit this file

auto lo
iface lo inet loopback

# "auto eth0" заменено на "allow-hotplug eth0", но
# после перезагрузки автоматически вставляется "auto eth0":
# (попытка избежать, чтобы eth0 иногда исчезал)
allow-hotplug eth0
auto eth0
iface eth0 inet dhcp

Да, я знаю, что не убрал верхнюю строку, хотя и менял файл. Но почему именно «allow-hotplug» помогает или отличается? В официальных мануалах этого не встречал, но на сайте ask-ubuntu (ссылка выше) делается упор на это. Может, просто не понимаю. Это обычно рекомендовано для LXC? Или связано с тем, что eth0 — виртуальный мост? (Если да, то я таких рекомендаций не видел.)

И ещё детали:

У меня система — небольшой маломощный HP t730, на нём работает pfSense. Сетевой интерфейс настроен как vmbr0 «Linux Bridge», который в LXC в вкладке «Network» настроен как мост с IP «dhcp». Этот же мост используется в pfSense-VM, где в настройках «Hardware» значение vmbr0 выставлено как сетевое устройство с «no VLAN», модель «VirtIO (paravirtualized)» и без галок в «Firewall», «Disconnect» и без ограничений по скорости (Rate limit пусто). Multiqueue не активирован.

Я думаю, что причина в LXC, хотя мост используется и в pfSense — просто к слову, чтобы показать, что NIC — не физический сетевой интерфейс...

Кто-нибудь может что-то посоветовать? Буду благодарен, если узнаю точно, что это рекомендуемое решение (и было бы интересно понять, почему именно оно работает), спасибо!

adystech

Guest

19.01.2023 05:33:00

Я только начал работать с контейнерами ProxMox lxc и столкнулся с точно такой же проблемой. В моём случае DHCP выдаёт dnsmasq, запущенный на роутере Asus Merlin. Раньше я использовал временный костыль — запускал `dhclient -v -r eth0 && dhclient -v eth0`, чтобы обновить аренду. Только что применил исправление с hot-plug для eth0, которое ты упомянул. Дам знать, если это реально решит проблему. К сожалению, на твой основной вопрос ответить не смогу...

virtManager

Guest

19.01.2023 13:07:00

Привет, @adystech. К сожалению, я не думаю, что изменение файла /etc/network/interfaces полностью решило проблему, потому что я выяснил, что она всё ещё сохраняется. Моя единственная — последняя — «панацея» сейчас — это cron-задача, которая пингует сервер каждые 5 минут. Если пинга нет, она перезагружает LXC. По сути, это bash-скрипт, вызываемый из cron (srv="192.168.xx.xx"):
Код:
ping -q -c1 "$srv" >/dev/null || pct reboot 103 --timeout 10
Перед перезагрузкой я также логирую проблему в /tmp/reboot.txt или что-то подобное, чтобы понимать, когда это происходит. Думаю, это скорее проблема LXC, чем Proxmox, но пока я не знаю, что именно, и решением моё оказалось крайне плохое — зато теперь мой файловый сервер недоступен не более 5 минут, и я не стал пинговать его каждую минуту... Надеюсь, это поможет, и спасибо за участие в обсуждении, может однажды кто-то, кто реально разбирается, напишет правильное решение!

adystech Guest	#4 0 24.01.2023 20:36:00 @virtManager ну вот, уже пять дней мои два контейнера lxc работают и общаются... Судя по логам службы сети, они несколько раз обновляли dhcp-аренду. Всё равно надо отдать тебе должное за идею с hotplug.

virtManager

Guest

25.01.2023 03:08:00

Рад, что у тебя получилось. Здорово, что команда "pct reboot" для моего LXC файлового сервера занимает всего несколько секунд (примерно 5-8 секунд, и сервер снова в деле). Мой LXC контейнер — вот этот: https://www.turnkeylinux.org/fileserver — сейчас он вообще не перезагружается по несколько недель подряд. Но в начале было намного хуже, иногда по несколько раз в неделю...

Вопрос: ты тоже используешь LXC контейнер с https://www.turnkeylinux.org, правильно? Наверняка он не такой же, как у меня, да? Просто пытаюсь понять, есть ли здесь какая-то закономерность, потому что лучшим решением было бы полностью избежать этой ситуации и не применять такое кривое «исправление» или решение...

Может, кто-то из нас или кто-то вообще должен когда-нибудь отправить запрос в поддержку на https://www.turnkeylinux.org/, возможно, это было бы лучше... Тогда настоящая проблема будет решена...

Но спасибо, что сообщил, что ты пошел по тому же пути, что и я, это тоже быстрое «решение» — или правильнее сказать «обходной путь».

adystech Guest	#6 0 25.01.2023 06:11:00 @virtManager Я использую обычный debian-11-standard как контейнер, но проблема (сбоев службы сети при попытке обновить DHCP-аренду и потеря внешнего соединения) проявляется там тоже.

virtManager

Guest

25.01.2023 13:06:00

Хорошо, спасибо... хм, у меня нет больше идей. Если ещё кто-то столкнётся с этой проблемой, напишите, какой LXC-контейнер вы используете или с каким видите эту проблему, может, мы заметим закономерность, которая приведёт к настоящему решению, а не к этому «автоматическому перезапуску» в качестве временного варианта...

Steve_P

Guest

02.02.2023 15:31:00

У меня точно такая же проблема с двумя контейнерами Debian 11, работающими на двух разных узлах кластера. Интересно, что оба, похоже, теряют свои аренды примерно в одно и то же время, если их запускать вместе. Поскольку они являются основным и вторичным внутренними DNS-серверами, их, как правило, запускают одновременно. Они получают свои аренды от Ubiquiti edgerouter. Другие DHCP-аренды вроде бы такой проблемы не имеют. Поскольку сбой происходит редко (от нескольких дней до пары недель), его очень трудно отследить.

virtManager

Guest

02.02.2023 23:25:00

Согласен — очень сложно отлаживать... Но, мне кажется, это проблема LXC, а не Proxmox. Нашёл пару похожих тем: https://www.reddit.com/r/Proxmox/comments/uf2bnr/lxc_container_keeps_losing_its_ip_address/ https://forum.proxmox.com/threads/debian-lxc-container-not-getting-an-ip.65719/ (рекомендуют отключить DHCP для IPv6) https://forum.proxmox.com/threads/lxc-lose-sometimes-network-connection.68686/ (рекомендуют отключить DHCP и сделать IP статическим) https://github.com/lxc/lxd/issues/7339 (возможно, это самое подходящее место, чтобы написать, если удастся точно определить причину или исправление) У меня есть файловый сервер на LXC, у которого раньше эта проблема возникала часто. Сейчас почти не пользуюсь им. Уже три недели работает без перезагрузки. Когда сбой происходит редко, его сложно отследить, и из-за этого сложно экспериментировать. К тому же я предпочитаю использовать DHCP, а не статический IP. Возможно, все мы пользуемся DHCP и в этом проблема именно с DHCP для LXC. Было бы здорово, если бы удалось точнее описать проблему, например, тут https://github.com/lxc/lxd/issues/, но, похоже, мы всё ещё только догадываемся... Мне этот вопрос всё ещё интересен, но, к счастью, теперь вижу это редко (странно, ведь я не менял настройки)...

adystech

Guest

#10

27.02.2023 05:27:00

Предложение отключить IPV6 в конфигурации proxmox (установить статический режим без значения IPV6) кажется рабочим решением, после применения которого у меня почти месяц не было проблем с сетью в трёх контейнерах.

awado

Guest

#11

11.03.2023 18:28:00

Хочу добавить, у меня такая же проблема на LXC с обратным прокси, установлена обычная Debian 11, только с nginx и lego. Отключение IPv6 не помогло, он уже был выключен на роутере и в proxmox. Проблема возникает примерно раз в день. Перезагрузка её решает. Время аренды DHCP у меня стоит на 24 часа, что, действительно, может указывать в правильном направлении – раз в день. Логи роутера (он же DHCP-сервер) не показывают никаких ошибок DHCP. Также ничего не найдено в логах LXC или proxmox.

awado Guest	#12 0 18.03.2023 12:55:00 Есть ли какой-нибудь способ отлаживать контейнер не через командную строку? (Потому что это вообще никуда не годится из-за долгого ожидания.)

nickrout

Guest

#13

09.04.2023 04:10:00

У меня с этим тоже проблемы. Что-то мешает обновлению DHCP. Логирую сервер DHCP (pi с pi-hole) и при попытке обновить аренду через dhclient сервер не получает DHCP-пакетов. Перезапускаю LXC — всё работает, пакеты проходят. LXC на базе Debian 11.

kyob Guest	#14 0 23.06.2023 12:13:00 Кто-нибудь нашёл решение? У меня такая же проблема. DHCLIENT не обновляет IP-адрес. PROXMOX 7.4-14 и Debian 11 с LXC.

virtManager

Guest

#15

23.06.2023 22:00:00

Как уже говорил, я использую ужасное решение с cron-скриптом, который запускается примерно раз в 5 минут или около того (точно не помню), и проверяет сеть пингом: ПЛОХОЕ_РЕШЕНИЕ — и автоматически перезапускает LXC, если пинга нет. Если ты имеешь в виду «нормальное/реальное» решение, то я тоже надеюсь, что однажды эту проблему лучше поймут, появится достойное решение или, может быть, сам баг наконец правильно исправят, чтобы такое вообще не случалось...

maria.boukje

Guest

#16

13.07.2023 16:25:00

У меня была точно такая же проблема. Хотя она продолжала появляться после того, как я сменил IPv6 на статический с пустым IP. Потом я попробовал установить статический адрес для IPv4, но, к моему удивлению, проблема всё равно оставалась. Я проверил файл /etc/network/interfaces и обнаружил там старые интерфейсы, которые удалял ранее через интерфейс Proxmox. Например:
Code:
auto eth1
iface eth1 inet dhcp
Похоже, он их не очищает. Я их удалил — и проблема у меня решилась.

guletz Guest	#17 0 13.07.2023 18:43:00 Привет! У меня тоже много лет несколько CT с DHCP, и проблем никогда не было. Насколько я знаю, DHCP очень сильно зависит от времени и даты с обеих сторон — и сервера, и клиента. Для отладки проблемы хорошая идея — запустить tcpdump с обеих сторон. Из того, что я видел раньше, DHCP-клиент сбоит, если в сети есть проблемы (потеря, отбрасывание или ошибки пакетов). Удачи/Бафта!

Читают тему

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