Некоторые контейнеры докеров не запускаются из-за ошибки времени выполнения OCI после обновления до Virtuozzo 7

Хостинг-провайдер моего 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

1
задан 16 July 2020 в 17:51
1 ответ

Да, это проблема Strato... случилась после их технического обслуживания 15./16. июль 2020. Я уже отправил заявку... посмотрим, будет ли ответ.

Излишне говорить, что за последние 3-4 месяца у Strato были серьезные проблемы с производительностью, и недавно они были исправлены.

Теперь это новое техническое обслуживание на прошлой неделе снова все испортило.

РЕДАКТИРОВАТЬ:

Просто удалил контейнер(ы) с моего сервера и переустановил их. Теперь все снова работает хорошо. Может быть, это решение и для других?

1
ответ дан 19 July 2020 в 06:45

Теги

Похожие вопросы