Oracle JDB C Больше нет данных для чтения из сокета в RedHat 7.7 - PullRequest
1 голос
/ 25 мая 2020

Я получаю сообщение об ошибке «Нет данных для чтения из сокета» от sql -maven-plugin, пока он пытается подключиться и запустить выполнение.

Проблема в том, что я получаю эту ошибку только на ведомом сервере Jenkins, работающем с RedHat 7.7, но на моем Macbook Pro он работает нормально.

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

1 Ответ

1 голос
/ 25 мая 2020

Отказ от ответственности: я работаю с @ emanuel502

Добавление этого флага решает проблему: -Djava.security.egd=file:/dev/urandom

  • нам нужна энтропия для обеспечения безопасности (аутентификация, TLS)
  • по умолчанию jvm использует / dev / random в качестве источника энтропии (= в основном, случайность)
  • , но этот блокирует, если «недостаточно энтропии», а /dev/urandom isn ' t
  • в очень старых системах (linux kernel <<code>3.16, в то время как текущее - 5.6), /dev/random просто не имеет достаточной энтропии, чтобы быть полезным (есть инструменты, чтобы сделать это лучше, что системные администраторы могут установить)
  • , потому что наши подчиненные устройства jenkins работают на RedHat 7.7, а RedHat предоставляет только второстепенные обновления / обновления безопасности в основной версии, а RedHat 7 - с 2014 года (и они, вероятно, уже использовали старое ядро, then), мы используем ядро ​​3.10, что практически означает простые блоки cat / dev / random после нескольких байтов
  • иногда, у вас бывает достаточно энтропии в момент попытки, и вы можете не вижу проблем, так что это ди трудно отлаживать; в нашем случае сообщение было «Недостаточно данных для чтения из сокета» (вот и все). Я помню случай лет go, когда TLS-соединения были очень медленными / заблокированными по той же причине.

Мой личный вывод: никогда не верьте, что «он старый, значит, стабильный». В более новой системе (ядро 3.16 от 30 июня 2013 г.) вы даже не заметили бы этой проблемы. Использование RedHat (и даже отсутствие обновления с момента выхода RedHat 8 в прошлом году) сделало проблему из проблемы, которая решалась 7+ лет go. Мы потеряли на это дни

И я ничего не узнал: у меня уже была эта проблема 4 года go, но я думал, что никогда больше не увижу такую ​​систему в своей жизни, и я мог просто забыть об этом.

Источники:

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...