Хостинг-провайдер моего KVM (Strato) недавно обновил версию Virtuozzo, которую они использовали, с 6 до 7. С тех пор некоторые из моих контейнеров докеров не запускаются со следующим сообщением об ошибке:
❯ sudo docker start spring_webapp
Error response from daemon:
OCI runtime create failed: container_linux.go:349: starting container process caused
"process_linux.go:297: applying cgroup configuration for process caused
\"failed to set memory.kmem.limit_in_bytes,
because either tasks have already joined this cgroup
or it has children\"": unknown
Error: failed to start containers: spring_webapp
Единственное, что у контейнеров, которые не запускаются, похоже, общего - это то, что они содержат java webapp. Другие контейнеры, такие как gitlab или несколько экземпляров mariadb, запускаются нормально.
Поиск в Google сообщения об ошибке вернул несколько более старых проблем на github, но, похоже, они были исправлены много лет назад: https://github.com/opencontainers/runc/issues/1083
Я бегаю Ubuntu 18.04 LTS с участием докер 19.03.12.
Я уже открыл билет у моего хостинг-провайдера, но они ответили шаблонным ответом, что, поскольку у меня есть корневой сервер, они не могут мне помочь, в основном говоря, что это проблема с моей конфигурацией.
К сожалению, я недостаточно знаю об OpenVZ / Virtuozzo, чтобы опровергнуть их.
Любой намек, указывающий мне в правильном направлении, будет очень признателен :)
Вот вывод / proc / user_beancounters
❯ sudo cat /proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt
831745: kmemsize 564412416 766132224 9223372036854775807 9223372036854775807 0
lockedpages 0 16 9223372036854775807 9223372036854775807 0
privvmpages 5148863 5444666 9223372036854775807 9223372036854775807 0
shmpages 41758 74651 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numproc 919 919 1100 1100 0
physpages 1972269 2444334 8388608 8388608 0
vmguarpages 0 0 9223372036854775807 9223372036854775807 0
oomguarpages 2104451 2452167 0 0 0
numtcpsock 0 0 9223372036854775807 9223372036854775807 0
numflock 0 0 9223372036854775807 9223372036854775807 0
numpty 4 4 9223372036854775807 9223372036854775807 0
numsiginfo 16 129 9223372036854775807 9223372036854775807 0
tcpsndbuf 0 0 9223372036854775807 9223372036854775807 0
tcprcvbuf 0 0 9223372036854775807 9223372036854775807 0
othersockbuf 0 0 9223372036854775807 9223372036854775807 0
dgramrcvbuf 0 0 9223372036854775807 9223372036854775807 0
numothersock 0 0 9223372036854775807 9223372036854775807 0
dcachesize 353423360 552648704 9223372036854775807 9223372036854775807 0
numfile 6327 11230 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
dummy 0 0 9223372036854775807 9223372036854775807 0
numiptent 219 222 2000 2000 0
Да, это проблема Strato ... произошла после их обслуживания 15./16. Июль 2020 г. Я уже отправил заявку ... Посмотрим, будет ли ответ.
Излишне говорить, что у Strato были серьезные проблемы с производительностью в последние 3..4 месяца, и они были исправлены недавно.
Теперь это новое техническое обслуживание на прошлой неделе снова все испортило.
РЕДАКТИРОВАТЬ:
Просто удалил контейнер (ы) с моего сервера и переустановил их. Теперь все снова работает хорошо. Может быть, это решение и для других?