Логи переписки с glebfm@ чтобы освежить память. Вчера проверял на последнем образе: $ docker image pull alt:sisyphus sisyphus: Pulling from library/alt Digest: sha256:455829716ec290e7cc3205b660fda004bdf394559ac1e64760ac2fcd2949465f Status: Image is up to date for alt:sisyphus Konstantin Lepikhov, [26.03.19 17:30] привет! а ты случайно не в курсе, кто-то из basealt уже пробовал что-то из сизифа запускать в docker? Konstantin Lepikhov, [26.03.19 17:31] у меня тут возникла странная проблема - процессы залипают на FUTEX_WAIT_PRIVATE и отваливаются Konstantin Lepikhov, [26.03.19 17:31] причем это только с образами на базе сизифа, если пробовать с другими дистрибутивами все работает Konstantin Lepikhov, [26.03.19 17:32] я к тому что может ldv@ или ты что-то патчили в glibc насчет этих futex'ов Gleb Pfotenhauer-Malinowski, [26.03.19 21:40] Привет! Да вообще-то пробовали и запускали. Попробуй shaba@ потыкать, это с его подачи у нас вообще есть официальные образы. Gleb Pfotenhauer-Malinowski, [26.03.19 21:40] [In reply to Konstantin Lepikhov] Не, у нас glibc не про это запатчен всё же. Konstantin Lepikhov, [26.03.19 22:10] https://github.com/alt-cloud/docker-brew-alt Konstantin Lepikhov, [26.03.19 22:10] вот эти? Gleb Pfotenhauer-Malinowski, [26.03.19 22:19] Думаю, да. Gleb Pfotenhauer-Malinowski, [26.03.19 22:22] Вот эти точно https://hub.docker.com/_/alt Konstantin Lepikhov, [26.03.19 22:37] неа, с ними такая же беда Konstantin Lepikhov, [26.03.19 22:37] [pid 14204] sched_yield( <unfinished ...> [pid 14203] <... sched_yield resumed> ) = 0 [pid 14202] <... sched_yield resumed> ) = 0 [pid 14200] futex(0x7f4c1fe00250, FUTEX_WAIT_PRIVATE, 4294967295, {604745, 419503231} <unfinished ...> [pid 14199] sched_yield( <unfinished ...> [pid 14206] sched_yield( <unfinished ...> [pid 14205] futex(0x7f4c1fe00390, FUTEX_WAIT_PRIVATE, 4294967295, {604745, 420475110} <unfinished ...> [pid 14204] <... sched_yield resumed> ) = 0 [pid 14203] futex(0x7f4c1fe00310, FUTEX_WAIT_PRIVATE, 4294967295, {604745, 420467333} <unfinished ...> [pid 14202] sched_yield( <unfinished ...> [pid 14199] <... sched_yield resumed> ) = 0 [pid 14206] <... sched_yield resumed> ) = 0 [pid 14204] futex(0x7f4c1fe00350, FUTEX_WAIT_PRIVATE, 4294967295, {604745, 420422946} <unfinished ...> [pid 14202] <... sched_yield resumed> ) = 0 [pid 14199] sched_yield( <unfinished ...> [pid 14206] futex(0x7f4c1fe003d0, FUTEX_WAIT_PRIVATE, 4294967295, {604745, 420388440} <unfinished ...> [pid 14202] sched_yield( <unfinished ...> [pid 14199] <... sched_yield resumed> ) = 0 [pid 14202] <... sched_yield resumed> ) = 0 [pid 14199] futex(0x7f4c1fe00210, FUTEX_WAIT_PRIVATE, 4294967295, {6, 924334624} <unfinished ...> [pid 14202] futex(0x7f4c1fe002d0, FUTEX_WAIT_PRIVATE, 4294967295, {604745, 419326924} <unfinished ...> [pid 14201] <... epoll_wait resumed> [{EPOLLIN, {u32=11, u64=16643240306292031499}}], 512, -1) = 1 [pid 14201] timerfd_settime(11, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 [pid 14201] timerfd_settime(11, 0, {it_interval={0, 0}, it_value={0, 765546770}}, NULL) = 0 [pid 14201] epoll_wait(8, ^Cstrace: Process 14188 detached Konstantin Lepikhov, [26.03.19 22:37] вот так залипает процесс и все Konstantin Lepikhov, [26.03.19 22:38] [Forwarded from Алексей Гладков] А выяснится что каких-то модулей nss для glibc не хватает Konstantin Lepikhov, [26.03.19 23:20] просто раз есть проблемы с этими образами, куда ошибки вешать? Gleb Pfotenhauer-Malinowski, [27.03.19 00:29] Потыкай shaba@, а я в офисе ему тоже скажу что отдельный компонент в багзилле это хорошая идея. Konstantin Lepikhov, [27.03.19 00:29] окей Konstantin Lepikhov, [27.03.19 00:29] а я тока завел все на убунте )) Gleb Pfotenhauer-Malinowski, [27.03.19 00:31] Понимаю. Если расскажешь ребятам как воспроизвести, есть шанс, что в следующий раз будет лучше. :) Gleb Pfotenhauer-Malinowski, [27.03.19 00:35] А что ты в контейнере запускаешь? Konstantin Lepikhov, [27.03.19 01:21] жаббер сервер Konstantin Lepikhov, [27.03.19 01:21] самое интересное - jabberd2 работает, но с ним не работает jabber-muc (это чатики) Konstantin Lepikhov, [27.03.19 01:22] как раз jabber-muc вот так залипает Konstantin Lepikhov, [27.03.19 01:22] потом попробовал поставить ejabberd - так он весь залипает и вообще не запускается Konstantin Lepikhov, [27.03.19 01:23] сейчас у меня работает jabberd2 в отдельном контейнере, отдельно запущена mysql (на альтах, тоже работает), pyirct (на альтах, тоже работает) и jabber-muc на убунте под i386 ) Konstantin Lepikhov, [27.03.19 01:24] для ejabberd у меня Dockerfile - https://github.com/LAKostis/altlinux-ejabberd-docker Konstantin Lepikhov, [27.03.19 09:12] в общем для воспроизведения нужно создать контейнер с jabberd2 можно с настройками по умолчанию, и контейнер с jabber-muc где в качестве севера указать контейнер с jabberd2 и потом попробовать каким-то нибудь жаббер клиентом потыкать conference транспорт. Или просто попробовать поднять этот докер контейнер для ejabberd
В https://github.com/LAKostis/altlinux-ejabberd-docker/blob/master/Dockerfile я просто заменил FROM legionus/altlinux-initroot:x86_64 на FROM alt:sisyphus
Заметил похожую проблему с ejabberd на Sisyphus, без докера. Причём, если собрать текущие erlang, модули erlang и ejabberd из Sisyphus в p8 (там почти всё собирается без изменений), то в p8 оно работает без проблем.
(In reply to comment #2) > Заметил похожую проблему с ejabberd на Sisyphus, без докера. Причём, если > собрать текущие erlang, модули erlang и ejabberd из Sisyphus в p8 (там почти > всё собирается без изменений), то в p8 оно работает без проблем. учитывая, что на jabber-muc происходит тоже самое, это скорее системная проблема. Хотя, я не очень уверен, что ответственные за систему читают этот баг ;)
Нашёл проблему с зависимостями (provides), оформил https://bugzilla.altlinux.org/show_bug.cgi?id=36925 Проверьте, пожалуйста, если явно установить erlang-lager и erlang-goldrush, пропадает ли проблема?
(In reply to comment #4) > Нашёл проблему с зависимостями (provides), оформил > https://bugzilla.altlinux.org/show_bug.cgi?id=36925 > > Проверьте, пожалуйста, если явно установить erlang-lager и erlang-goldrush, > пропадает ли проблема? Да, после установки вышеозначенных пакетов, все заработало. Значит, все еще хуже, чем я думаю, ejabberd даже не пользуются, раз он просто не работает "из коробки".
Пока сделаю WORKSFORME
(В ответ на комментарий №5) > Да, после установки вышеозначенных пакетов, все заработало. Значит, все еще > хуже, чем я думаю, ejabberd даже не пользуются, раз он просто не работает "из > коробки". Пользуются, но при обновлении со старых версий ejabberd такая проблема не вылезала, поскольку проблема с provides появилась недавно, соответственно erlang-lager и erlang-goldrush присутствовали в системе и вполне нормально обновлялись.