Почему требуются десятки секунд для получения приглашения оболочки?

Именно своего рода регулярное возникновение, после SSHing к серверу (или даже открытие терминала на моем Mac), баннер входа в систему сразу печатает, но требуется ~10 секунд к минуте для приглашения оболочки появиться. После этого производительность прекрасна, и сетевая задержка весьма обычна.

Это не походит на в вычислительном отношении трудную, интенсивно использующую память, или задачу IO-heavy. Что это делает со всеми теми миллиардами циклов ЦП?

30
задан 15 September 2015 в 20:13
7 ответов

Это в большинстве случаев таймаут DNS-запроса.

Причина: Сервер пытается выполнить обратный DNS поиск по IP-адресу клиента и не получает ответа. Если A подключается к B, B пытается преобразовать IP-адрес A в имя.

Обходной путь: Введите IP-адрес и имя клиента в файл hosts сервера.

Решение: сделайте все хосты известными DNS-серверу.

.
2
ответ дан 28 November 2019 в 19:58

Вероятно, он либо ждет DNS, либо пытается аутентифицироваться через LDAP или что-то в этом роде.

Попробуйте добавить UseDNS no в /etc/ssh/sshd_config

Если он также делает это при локальном входе в систему, проверьте, не работают ли медленно или не отвечают ли какие-либо LDAP-серверы или DNS-серверы, которые вы настроили.

.
22
ответ дан 28 November 2019 в 19:58

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

Скорее всего, ваша проблема сводится к одному из нескольких.

Если в вашем профиле или bashrc есть дорогие вещи, подумайте об их урезании.

Если ваш профиль или bashrc используют обратный DNS поиск (для установки подсказки или чего-то еще), исправьте DNS или используйте вместо этого имя хоста.

Оболочки открывают много файлов, помимо всего прочего, во время инициализации. Если загрузка системы велика, то она будет часто появляться здесь.

Если баннер является пре-аутентификацией, то это также может быть медленной аутентификацией (pam, LDAP и т.д.).

Однако, это может быть ни одна из этих вещей. Удивительное количество вещей происходит прямо перед отображением подсказки!

.
33
ответ дан 28 November 2019 в 19:58

Если это сервер Ubuntu, то при настройке входа в систему по умолчанию проверяется, обновляются ли какие-либо пакеты при каждом запуске оболочки входа в систему. Если списков пакетов нет в дисковом кэше, это может занять секунду или две даже на быстром простаивающем рабочем столе.

$ ssh localhost 
Welcome to Ubuntu 15.04 (GNU/Linux 3.19.0-26-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

*** System restart required ***
Last login: Sat Sep 12 01:38:38 2015 from localhost

Для генерации этого сообщения "restart required" нужно было проверить, что запущенное в данный момент ядро не является ядром по умолчанию, установленным по умолчанию. (т.е. было ядро, и я еще не перезагрузился.) Это также напечатает количество доступных обновлений безопасности, если таковые имеются.

Я думаю, что это значительное замедление при входе в Ubuntu, которое было введено недавно.

Если нет, то проблема может быть в вашем ~/.bash_profile / ~/.bashrc.

Пытались ли вы войти на сервер с самого сервера (ssh localhost)? Или войти во 2-й раз сразу? (Чтобы проверить, намного ли быстрее, когда вещи кэшируются)

.
3
ответ дан 28 November 2019 в 19:58

Одна из возможностей (охваченных другими ответами) заключается в том, что процесс настройки самой SSH-сессии - это то место, где теряется время.

Другая альтернатива заключается в том, что ваши скрипты запуска оболочки, выполняемые на удаленной машине после установки сеанса SSH, имеют что-то, что занимает много времени (возможно, пытаясь получить доступ к некоему нарушенному сетевому подключению). Вы можете отлаживать эту вторую возможность следующим образом:

Временно добавьте следующее в верхнюю часть вашего ~/.bash_profile:

set -x
PS4='+ $(date "+%s.%N")\011 '

Набор -x включает отладку для каждой выполняемой команды оболочки. Переменная PS4 управляет тем, как представлена отладка - именно в этом случае мы используем дату для добавления временных меток.

Затем вы можете проанализировать временные метки вывода отладки, чтобы посмотреть, какие команды в ваших скриптах запуска занимают слишком много времени.

.
6
ответ дан 28 November 2019 в 19:58

Многое узнал из этой темы. В моем случае нарушителем был nvm:

export NVM_DIR="$HOME/.nvm"
[ -s "/usr/local/opt/nvm/nvm.sh" ] && . "/usr/local/opt/nvm/nvm.sh"  # This loads nvm
[ -s "/usr/local/opt/nvm/etc/bash_completion" ] && . "/usr/local/opt/nvm/etc/bash_completion"  # This loads nvm bash_completion
0
ответ дан 15 December 2020 в 15:21

для будущих посетителей, у меня была miniconda на моей машине, и ее запись.bashrc была той, которая вызывала мое отложенное приглашение оболочки. я не нуждался в conda, поэтому удалил его запись из.bashrc, которая выглядела как эта

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/home/<YOUR_USER>/miniconda3/bin/conda' 'shell.bash' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
    if [ -f "/home/<YOUR_USER>/miniconda3/etc/profile.d/conda.sh" ]; then
       . "/home/<YOUR_USER>/miniconda3/etc/profile.d/conda.sh"
    else
        export PATH="/home/<YOUR_USER>/miniconda3/bin:$PATH"
    fi
fi
unset __conda_setup
# <<< conda initialize <<< 
0
ответ дан 8 October 2021 в 09:40

Теги

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