VPS периодически становится недоступным

Для начала стоит глянуть через инструменты предоставляемые хостингом на «реальную» консоль - через iKVM и подобные вещи, зависит от того что предоставляет хостер. Может у тебя там kernel panic, а ребутаться при panic ты не разрешил.

grsecurity есть?

Да, но при обновлении на 4.7.10-hardened в конфиге ничего не менялось. На 4.4.8-hardened-r1 всё работало хорошо.

4.7.7 из-за CONFIG_PAX_SIZE_OVERFLOW_EXTRA падало в kernel panic через несколько часов, поэтому спросил. В 4.7.10 вроде пофиксили, поэтому не знаю

падало в kernel panic

а что на старых версиях с этим багом? да они бы еще вот это пофиксили, правда конечно не серверная проблема. https://bugs.gentoo.org/show_bug.cgi?id=584378

А если откатиться на предыдущее ведро?

кастую kernel panic

Для начала стоит глянуть через инструменты предоставляемые хостингом

Оказалось, что консоль была жива после того, как vps перестал отвечать. Удалось туда зайти и посмотреть логи. В вот последняя информация из /var/log/syslog:

[Oct 30 01:42:20 myhostname dhcpcd[1857]: eth0: deleted route to ***.***.***.0/23]

И первый раз проблема случилась в первые же 12 часов после установки vmlinuz-4.7.10-hardened вместо vmlinuz-4.7.6-hardened. При обновлении старый конфиг был скопирован в директорию с новыми исходниками, сделан make silentoldconfig и выключен PAX_SIZE_OVERFLOW_EXTRA.

Если ты смог залогиниться - тогда что с настройками сети? ping с самого VPS в такие моменты идет?

что с настройками сети?

Вот вывод ip route при нормальной работе vps, когда всё хорошо:

# ip route
default via 111.222.333.1 dev eth0  src 111.222.333.87  metric 2 
111.222.333.0/23 dev eth0  proto kernel  scope link  src 111.222.333.87  metric 2 
127.0.0.0/8 dev lo  scope host 
169.***.***.254 via 111.222.333.1 dev eth0  src 111.222.333.87  metric 2

А вот что остаётся после сбоя:

# ip route
111.222.333.0/23 dev eth0  proto kernel  scope link  src 111.222.333.87
127.0.0.0/8 dev lo  scope host

В /etc/conf.d/net указано только это:

config_eth0="dhcp"
dns_domain_lo="example.com"

ping с самого VPS в такие моменты идет?

Да, после сбоя пинговал с vps адрес самого vps, т.е. 111.222.333.87, и пинг шёл. А вот домен example.com, который указывает на 111.222.333.87, не пингуется.

Отваливается default route, при этом сам адрес на интерфейсе судя по таблице маршрутизации остаётся.

111.222.333.1(адрес шлюза по умолчанию) при таком раскладе пингуется?

config_eth0=«dhcp»

Это требование хостера? Статику прописать и попробовать можно?

Похоже на регрессию в ведре. Вот у меня.в конфиге dnsmasq прописано 72h, что бы это ни значило. Но и через 3 дня, и через больше дней коннект есть, и даже IP между подключенными устройствами не перемешиваются

CriticalConnection=
When true, the connection will never be torn down even if the DHCP lease expires. This is contrary to the DHCP specification, but may be the best choice if, say, the root filesystem relies on this connection. Defaults to false.

111.222.333.1(адрес шлюза по умолчанию) при таком раскладе пингуется?

Нет, не пингуется.

Статику прописать и попробовать можно?

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

Нет, не пингуется

Тогда статику даже не пробуй - не поможет. Проблема с сетью, скорее всего с драйвером сетевухи

Почему на других компьютерах (с тем же ядром) эта проблема не возникает?

На VPS от этого же хостера? Или на твоих PC? Если второе - подозреваю, что драйвера для сети(на VPS - для виртуальной, у тебя - для реальной) различаются.

Дай выхлоп lspci -k с VPS

lspci -k

Или на твоих PC?

Да, на рабочей станции.

Тогда статику даже не пробуй - не поможет. Проблема с сетью, скорее всего с драйвером сетевухи

Спасибо за советы. Я пока откатился на 4.7.6-hardened. Сколько времени на нём можно протянуть, регулярно обновляясь?

Даже если ядро удалят из дерева portage - все равно у тебя останутся исходники, если надо будет вдруг пересобрать. Теоретически(не учитывая security проблемы) - пока какой-нибудь ключевой компонент системы не перестанет быть совместимым с данным ядром. Практически - минимум года 3. Потом может начаться какое-нибудь веселье, например с udev(прецеденты были) или glibc(тут я не застал, слава яйцам)