несуществующий dbus-daemon zombie замерзает ssh в течение 30 секунд [dубликат]

У меня была такая же проблема. Убедитесь, что в ~/.local/share/applications нет пользовательского файла nautilus-home.desktop. Когда я удалил это, все снова заработало.

Я создал один экземпляр в 11.04, я думаю, что что-то изменилось в 11.10.

20
задан 5 November 2010 в 17:59

58 ответов

Обычно это результат pam_motd восстановления файла /etc/motd. Вы можете проверить отдельные сценарии в /etc/update-motd.d, чтобы увидеть, что что-то особенно медленное.

18
ответ дан 25 July 2018 в 13:28
  • 1
    Brilliant. Это был файл 90-обновлений - доступный для меня. Также 50-ландшафт-sysinfo не самый быстрый. – Matt H 13 September 2013 в 05:16

Обычно это результат pam_motd восстановления файла /etc/motd. Вы можете проверить отдельные сценарии в /etc/update-motd.d, чтобы увидеть, что что-то особенно медленное.

18
ответ дан 1 August 2018 в 20:17

Обычно это результат pam_motd восстановления файла / etc / motd . Вы можете проверить отдельные сценарии в /etc/update-motd.d , чтобы увидеть, что что-то особенно медленное.

18
ответ дан 4 August 2018 в 11:58

Обычно это результат pam_motd восстановления файла / etc / motd . Вы можете проверить отдельные сценарии в /etc/update-motd.d , чтобы увидеть, что что-то особенно медленное.

18
ответ дан 5 August 2018 в 20:04

Обычно это результат pam_motd восстановления файла / etc / motd . Вы можете проверить отдельные сценарии в /etc/update-motd.d , чтобы увидеть, что что-то особенно медленное.

18
ответ дан 7 August 2018 в 13:28

Обычно это результат pam_motd восстановления файла / etc / motd . Вы можете проверить отдельные сценарии в /etc/update-motd.d , чтобы увидеть, что что-то особенно медленное.

18
ответ дан 10 August 2018 в 02:01

Обычно это результат pam_motd восстановления файла / etc / motd . Вы можете проверить отдельные сценарии в /etc/update-motd.d , чтобы увидеть, что что-то особенно медленное.

18
ответ дан 15 August 2018 в 13:48
  • 1
    Brilliant. Это был файл 90-обновлений - доступный для меня. Также 50-ландшафт-sysinfo не самый быстрый. – Matt H 13 September 2013 в 05:16

Если оба параметра PermitEmptyPassword и UsePAM включены, сервер OpenSSH всегда пытается выполнить аутентификацию с пустым паролем, который требуется в качестве знака того, что для рассматриваемой учетной записи не требуется аутентификация. Он делает это, как только начинается процесс аутентификации, в обоих протоколах, а не в ответ на любой «реальный» запрос аутентификации от клиента. OpenSSH разрешает только такой доступ, если установлен флаг sshd_config PermitEmptyPassword; к сожалению, способ написания кода, он в любом случае выполняет проверку пароля и, таким образом, показывает PAM как сбой.

Итак: отключить PermitEmptyPassword или UsePAM, но помните: без PAM, вы не сможете войти в систему без ключа.

Ссылка: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG- с

2
ответ дан 25 July 2018 в 13:28
  • 1
    Я добавил этот ответ на этот старый вопрос, потому что я столкнулся с той же проблемой (медленный вход в систему), но ничего здесь не решила моя проблема. Это мое решение. – Alessandro Pezzato 2 October 2012 в 01:55

Проверьте системные журналы в / var / log, вы можете найти сообщение с соответствующей ошибкой / временем ожидания.

0
ответ дан 25 July 2018 в 13:28

Если у вас есть время ожидания перед

Измените /etc/sshd_config

и установите (или добавьте)

UseDNS no

или добавьте свой ip в /etc/hosts, если его статический локальный

0
ответ дан 25 July 2018 в 13:28
  • 1
    похоже, какая-то сетевая проблема удерживала статистику? – 0xF2 9 January 2013 в 01:06

Возможно, вы захотите попытаться контролировать запущенные процессы во время входа на сервер из уже подключенного входа (или другой консоли). Есть возможность определить, какие процессы являются наиболее активными или использовать большинство CPU в то время.

Ниже приведен один возможный метод:

Попробуйте войти в систему на другой консоли. Запустите top, чтобы узнать, что произойдет. Войдите в систему на 1-й консоли.

Обратите внимание, что если задержка не вызвана некоторыми вычислениями с использованием ЦП, вы не заметите что-то не на месте. В этом случае проблема может быть связана с привязкой ввода / вывода (ожидая некоторого чтения / записи на диске или сетевого ответа).

0
ответ дан 25 July 2018 в 13:28
  • 1
    наверх показывает это (при входе в систему): 12112 sshd 20 0 6988 856 412 S 13,9 0,1 0: 00,42 sshd – Wolfy 5 November 2010 в 18:46
  • 2
    @Idi, я думаю, что это должен быть комментарий. – Tshepang 6 November 2010 в 02:21

В моем ограниченном опыте, когда шпатлевка работает, но Linux, Ubuntu в этом случае, нет, она обычно сохраняется. Проблемы с сетью или сервером повлияют на обе клиентские ОС.

Вы можете использовать приведенную выше опцию keep alive в командной строке, но это довольно утомительно для ввода.

Легче редактировать несколько файлов конфигурации.

Если у вас есть root access, и вы хотите включить его автоматически для всех пользователей, отредактируйте /etc/ssh/ssh_config, добавьте

KeepAlive yes ServerAliveInterval 120

Если у вас нет корня доступ или включить его для одного пользователя, отредактируйте ~/.ssh/config и добавьте те же две строки.

2
ответ дан 25 July 2018 в 13:28

Из вашего описания это больше похоже на проблему с сетью. Чтобы диагностировать:

Запустите ssh с параметром -v, чтобы быть подробным. Попробуйте запустить пинг на SSH-сервер, к которому вы подключаетесь, и посмотреть, будет ли это также зависать одновременно. Попробуйте другой способ передачи на тот же сервер. Например, wget с параметром -limit-rate для извлечения файла через HTTP и потребовать достаточно много времени, чтобы он мог вызвать «зависание» поведения. Посмотрите, висит ли он только на холостом ходу или даже если вы делаете что-то в данный момент. Если он висит на ходу, диагностика -v, вероятно, скажет вам об этом, и в этом случае совет по использованию keepalive может помочь (ssh -o «TCPKeepAlive yes»)

Если вы можете подключиться к OK с помощью Windows и PuTTY, это, вероятно, не проблема на стороне сервера.

4
ответ дан 25 July 2018 в 13:28

Я думаю, что когда вы входите в систему, ubuntu выполняет один или несколько из этих файлов:

/etc/bash.bashrc ~/.bash_profile ~/.bashrc

Вы могли видеть, что в них, а может быть, даже попытаться выполнить их, чтобы увидеть, что так долго.

2
ответ дан 25 July 2018 в 13:28

Если оба параметра PermitEmptyPassword и UsePAM включены, сервер OpenSSH всегда пытается выполнить аутентификацию с пустым паролем, который требуется в качестве знака того, что для рассматриваемой учетной записи не требуется аутентификация. Он делает это, как только начинается процесс аутентификации, в обоих протоколах, а не в ответ на любой «реальный» запрос аутентификации от клиента. OpenSSH разрешает только такой доступ, если установлен флаг sshd_config PermitEmptyPassword; к сожалению, способ написания кода, он в любом случае выполняет проверку пароля и, таким образом, показывает PAM как сбой.

Итак: отключить PermitEmptyPassword или UsePAM, но помните: без PAM, вы не сможете войти в систему без ключа.

Ссылка: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG- с

2
ответ дан 1 August 2018 в 20:17
  • 1
    Я добавил этот ответ на этот старый вопрос, потому что я столкнулся с той же проблемой (медленный вход в систему), но ничего здесь не решила моя проблема. Это мое решение. – Alessandro Pezzato 2 October 2012 в 01:55

Проверьте системные журналы в / var / log, вы можете найти сообщение с соответствующей ошибкой / временем ожидания.

0
ответ дан 1 August 2018 в 20:17

Если у вас есть время ожидания перед

Измените /etc/sshd_config

и установите (или добавьте)

UseDNS no

или добавьте свой ip в /etc/hosts, если его статический локальный

13
ответ дан 1 August 2018 в 20:17
  • 1
    похоже, какая-то сетевая проблема удерживала статистику? – 0xF2 9 January 2013 в 01:06

Возможно, вы захотите попытаться контролировать запущенные процессы во время входа на сервер из уже подключенного входа (или другой консоли). Есть возможность определить, какие процессы являются наиболее активными или использовать большинство CPU в то время.

Ниже приведен один возможный метод:

Попробуйте войти в систему на другой консоли. Запустите top, чтобы узнать, что произойдет. Войдите в систему на 1-й консоли.

Обратите внимание, что если задержка не вызвана некоторыми вычислениями с использованием ЦП, вы не заметите что-то не на месте. В этом случае проблема может быть связана с привязкой ввода / вывода (ожидая некоторого чтения / записи на диске или сетевого ответа).

0
ответ дан 1 August 2018 в 20:17
  • 1
    наверх показывает это (при входе в систему): 12112 sshd 20 0 6988 856 412 S 13,9 0,1 0: 00,42 sshd – Wolfy 5 November 2010 в 18:46
  • 2
    @Idi, я думаю, что это должен быть комментарий. – Tshepang 6 November 2010 в 02:21

В моем ограниченном опыте, когда шпатлевка работает, но Linux, Ubuntu в этом случае, нет, она обычно сохраняется. Проблемы с сетью или сервером повлияют на обе клиентские ОС.

Вы можете использовать приведенную выше опцию keep alive в командной строке, но это довольно утомительно для ввода.

Легче редактировать несколько файлов конфигурации.

Если у вас есть root access, и вы хотите включить его автоматически для всех пользователей, отредактируйте /etc/ssh/ssh_config, добавьте

KeepAlive yes ServerAliveInterval 120

Если у вас нет корня доступ или включить его для одного пользователя, отредактируйте ~/.ssh/config и добавьте те же две строки.

2
ответ дан 1 August 2018 в 20:17

Из вашего описания это больше похоже на проблему с сетью. Чтобы диагностировать:

Запустите ssh с параметром -v, чтобы быть подробным. Попробуйте запустить пинг на SSH-сервер, к которому вы подключаетесь, и посмотреть, будет ли это также зависать одновременно. Попробуйте другой способ передачи на тот же сервер. Например, wget с параметром -limit-rate для извлечения файла через HTTP и потребовать достаточно много времени, чтобы он мог вызвать «зависание» поведения. Посмотрите, висит ли он только на холостом ходу или даже если вы делаете что-то в данный момент. Если он висит на ходу, диагностика -v, вероятно, скажет вам об этом, и в этом случае совет по использованию keepalive может помочь (ssh -o «TCPKeepAlive yes»)

Если вы можете подключиться к OK с помощью Windows и PuTTY, это, вероятно, не проблема на стороне сервера.

4
ответ дан 1 August 2018 в 20:17

Я думаю, что когда вы входите в систему, ubuntu выполняет один или несколько из этих файлов:

/etc/bash.bashrc ~/.bash_profile ~/.bashrc

Вы могли видеть, что в них, а может быть, даже попытаться выполнить их, чтобы увидеть, что так долго.

2
ответ дан 1 August 2018 в 20:17

Если оба параметра PermitEmptyPassword и UsePAM включены, сервер OpenSSH всегда пытается выполнить аутентификацию с пустым паролем, который требуется в качестве знака того, что аутентификация не требуется для учетной записи в вопрос. Он делает это, как только начинается процесс аутентификации, в обоих протоколах, а не в ответ на любой «реальный» запрос аутентификации от клиента. OpenSSH разрешает только такой доступ, если установлен флаг sshd_config PermitEmptyPassword ; к сожалению, способ написания кода, он в любом случае выполняет проверку пароля и, таким образом, показывает PAM как сбой.

Итак: отключить PermitEmptyPassword или UsePAM , но помните: без PAM вы не сможете войти в систему без ключа.

Ссылка: https://groups.google.com/forum/?fromgroups = #! тема / comp.security.ssh / wExY8lWlG-с

2
ответ дан 4 August 2018 в 11:58

Проверьте системные журналы в / var / log, вы можете найти сообщение с соответствующей ошибкой / временем ожидания.

0
ответ дан 4 August 2018 в 11:58

Если у вас есть также время ожидания перед

Изменить / etc / sshd_config

и установить (или добавить)

   ИспользоватьDNS no  

или добавить свой ip в / etc / hosts , если его статический локальный

13
ответ дан 4 August 2018 в 11:58

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

Ниже приведен один возможный метод:

  1. Попробуйте войти в систему на одном из следующих способов:
  2. Запустите top , чтобы узнать, что произойдет.
  3. Войдите в систему на 1-й консоли.

Обратите внимание, что если задержка не вызвана некоторыми вычислениями с использованием ЦП, вы не заметите что-то не на месте. В этом случае проблема может быть связана с привязкой ввода / вывода (ожидая некоторого чтения / записи на диске или сетевого ответа).

0
ответ дан 4 August 2018 в 11:58

В моем ограниченном опыте, когда шпатлевка работает, но Linux, Ubuntu в этом случае, нет, она обычно сохраняется. Проблемы с сетью или сервером повлияют на обе клиентские ОС.

Вы можете использовать приведенную выше опцию keep alive в командной строке, но это довольно утомительно для ввода.

Легче редактировать несколько файлов конфигурации.

Если у вас есть root access и хотите включить его автоматически для всех пользователей, отредактируйте / etc / ssh / ssh_config , добавьте

  KeepAlive yes ServerAliveInterval 120  

Если у вас нет доступа root или для его включения для одного пользователя, отредактируйте ~ / .ssh / config и добавьте те же две строки.

2
ответ дан 4 August 2018 в 11:58

Из вашего описания это больше похоже на проблему с сетью. Чтобы выполнить диагностику:

  • Запустите ssh с параметром -v, чтобы быть подробным.
  • Попробуйте запустить ping на сервер SSH, к которому вы подключаетесь, и посмотрите, зависает в то же время.
  • Попробуйте другой тип передачи на тот же сервер. Например, wget с параметром -limit-rate для извлечения файла через HTTP и потребовать достаточно долго, чтобы он мог вызвать «зависающее» поведение.
  • Посмотрите, зависает ли он только в режиме ожидания или даже если вы делаете что-то в данный момент. Если он висит на холостом ходу, диагностика -v, вероятно, скажет вам об этом, и в этом случае совет по использованию keepalive может помочь (ssh -o «TCPKeepAlive yes»)

Если вы можете подключиться ОК с Windows и PuTTY, это, вероятно, не проблема на стороне сервера.

4
ответ дан 4 August 2018 в 11:58

Я думаю, что при входе в систему ubuntu выполняет один или несколько из этих файлов:

  /etc/bash.bashrc ~ / .bash_profile ~ / .bashrc  

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

2
ответ дан 4 August 2018 в 11:58

Если оба параметра PermitEmptyPassword и UsePAM включены, сервер OpenSSH всегда пытается выполнить аутентификацию с пустым паролем, который требуется в качестве знака того, что аутентификация не требуется для учетной записи в вопрос. Он делает это, как только начинается процесс аутентификации, в обоих протоколах, а не в ответ на любой «реальный» запрос аутентификации от клиента. OpenSSH разрешает только такой доступ, если установлен флаг sshd_config PermitEmptyPassword ; к сожалению, способ написания кода, он в любом случае выполняет проверку пароля и, таким образом, показывает PAM как сбой.

Итак: отключить PermitEmptyPassword или UsePAM , но помните: без PAM вы не сможете войти в систему без ключа.

Ссылка: https://groups.google.com/forum/?fromgroups = #! тема / comp.security.ssh / wExY8lWlG-с

2
ответ дан 5 August 2018 в 20:04

Проверьте системные журналы в / var / log, вы можете найти сообщение с соответствующей ошибкой / временем ожидания.

0
ответ дан 5 August 2018 в 20:04

Другие вопросы по тегам:

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