Я пытаюсь помочь разработчику приложения, которое хотел бы использовать для устранения неполадок при использовании Corba Server в Linux. Я сузил проблему до tnameserv
подготовка после вызова занимает более 3 минут.
Что именно tnameserv
пытаюсь сделать за эти 3 минуты и могу ли я как-нибудь ускорить это? Приложение не удалось, потому что оно попыталось выполнить 5 попыток подключения с интервалом в 1 секунду между попытками; что, очевидно, не дает tnameserv достаточно времени, чтобы подготовиться. Я использую Java 6u17 в Slackware 13.0
В случае, если это имеет значение. Фактическое обращение к tnameserv
следующее:
tnameserv -ORBInitialPort 23423
После запуска этой команды в оболочке кажется, что она зависает примерно до 3-х минутной отметки, когда я наконец вижу, что она отображает «Готово».
Я сделал strace -f tnameserv -ORBInitialPort 23423
и я вижу множество вызовов gettimeofday (), clock_gettime () и futex (), из которых последний всегда возвращает '-1 ETIMEDOUT (время ожидания соединения истекло). У меня такое чувство, что это связано с моей проблемой, но я не знаю, как и почему.
Вот лишь небольшая часть того, что я вижу в strace. Может ли кто-нибудь воспроизвести и / или понять это?
[pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49903084}) = -1 ETIMEDOUT (Connection timed out) [pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329619, 995857482}) = 0 [pid 30950] gettimeofday({1260930158, 92108}, NULL) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329619, 995996617}) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329619, 996088536}) = 0 [pid 30950] gettimeofday({1260930158, 92328}, NULL) = 0 [pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 92424295}) = 0 [pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49903705}) = -1 ETIMEDOUT (Connection timed out) [pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 46761098}) = 0 [pid 30950] gettimeofday({1260930158, 143084}, NULL) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 46913924}) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 47006961}) = 0 [pid 30950] gettimeofday({1260930158, 143303}, NULL) = 0 [pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 143398317}) = 0 [pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49904683}) = -1 ETIMEDOUT (Connection timed out) [pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 97818379}) = 0 [pid 30950] gettimeofday({1260930158, 194127}, NULL) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 97957235}) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 98049154}) = 0 [pid 30950] gettimeofday({1260930158, 194346}, NULL) = 0 [pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 194441349}) = 0 [pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49904651}) = -1 ETIMEDOUT (Connection timed out) [pid 30950] futex(0x8098a28, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 148806370}) = 0 [pid 30950] gettimeofday({1260930158, 245055}, NULL) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 148947182}) = 0 [pid 30950] clock_gettime(CLOCK_MONOTONIC, {329620, 148981547}) = 0 [pid 30950] gettimeofday({1260930158, 245280}, NULL) = 0 [pid 30950] clock_gettime(CLOCK_REALTIME, {1260930158, 245374859}) = 0 [pid 30950] futex(0x8128e14, FUTEX_WAIT_PRIVATE, 1, {0, 49905141}) = -1 ETIMEDOUT (Connection timed out)
Оказывается, проблема в брандмауэре. Wireshark не показал ничего полезного, потому что брандмауэр отбрасывал определенный пакет. Хотя я несколько раз просматривал журналы брандмауэра, чтобы убедиться, что это не так, оказалось, что я искал не в том месте. Я упустил из виду тот факт, что этот tnameserv был осведомлен о IPv6 (поскольку он был привязан к ::: 23423), и беглый взгляд на мой скрипт брандмауэра показал, что я регистрировал связанные с IPv6 пакеты в другом месте, чем мои пакеты IPv4. Это не было недосмотром, но это нужно было сделать, потому что ip6tables в настоящее время не поддерживает цель -j ULOG.
Короче говоря, включение обратной связи для IPv6 устранило проблему, и tnameserv почти мгновенно вернул сообщение «Готово».
Я не могу решить вашу проблему напрямую, но опыт подсказывает мне, что чаще всего необъяснимые задержки продолжительностью от трех до пяти минут являются результатом ожидания тайм-аутов DNS.
Требует ли ваша конфигурация чего-либо по имени хоста?