Java же!

И насколько длинный ps у твоего сервера? Что на нём крутится? Как с памятью дела?

Твой ответ мы отошлём телепатам по почте на тот курорт, на котором они сейчас отдыхают. Так что не взыщи, если долго не будет ответов по сути.

повторить не смог

Описание проблемы - как будто школьник писал - понимаю. Но, черт возьми, проблема именно такая! И я не школьник, уж поверьте =)

Проблема не в длине ps, думаю. На сервере пока ничего не крутится, памяти 24 GB.

Некоторые команды почему-то отрубают консоль напрочь. Не сервер вырубают, а консоль. Например, смотрю top. Нажимаю «с» - чтобы смотреть список процессов с аргументами, и консоль виснет. Может, как-то с шириной консоли связано?

проблем с mtu нет?

Я тоже сначала на MTU подумал. У меня помимо этого еще 5 серверов у этого провайдера, подобных проблем не было. Везде MTU=1500.

Попробовал 1400 поставить - то же самое. Стабильно вырубает консоль на «ps -ef|grep something».

Верю, верю. Ну sshd_config выкини тогда что ли.

Стандартный Ubuntu-овский:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Попробуй в конфиге клиента включить кипаливы и указать таймауты и через сколько потеряных пакетов рвать коннект. Однажды это решило многие мои проблемы.

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

Стабильно вырубает консоль на «ps -ef|grep something».

ps -ef|grep --color=never something

результат тот же ?

и какие ещё команды вырубают консоль ?

кстати про ps «The utility does not correctly display argument lists containing multibyte characters.»

кстати про ps «The utility does not correctly display argument lists containing multibyte characters.»

тогда бы консоль висла и при простом ps -ef ?

работает ли pgrep -lf java

у меня такое было, когда работал через OpenVPN over udp, переключил на tcp - все заработало. Ковыряться не стал. Причем до этого стабильно и долго работало, потом вот неожиданно стало как у тебя.

тогда бы консоль висла и при простом ps -ef ?

не факт..grep все-таки нарушает поток символов и из случайно встретившихся на разных строках DC1 DC0 вполне мог один выкусить

а вообще информации нехватает. Неплохо-бы знать что за терминал используется, увидеть переменные TERM COLUMNS COLS в терминале и в сессии ssh. Выхлоп stty тоже не помешал-бы. И надеюсь ssh-сессия чистая ? Безо всяких mc, screen на концах ??

автор говорит, что на той-же площадке ещё 5 его серверов, думаю что под тем-же дистрибутивом с тем-же софтом, поэтому варианты неправильно настроенной сети или сбойного ssh крайне маловероятны. Прям таки даже интерестно что это за такие «детские грабельки» :)

не давно была такая же проблема вылечилось через TCPMSS в iptables(проблема была в MTU). Некоторые команды(не всегда выдающие что-то большое) вешали консоль SSH намертво

Дополнительные данные

ps -ef|grep --color=never something
ps -ef
pgrep -lf java

- все эти команды тоже вешают консоль.

Попробуй в конфиге клиента включить кипаливы и указать таймауты и через сколько потеряных пакетов рвать коннект. Однажды это решило многие мои проблемы.

Да, это включено.

у меня такое было, когда работал через OpenVPN over udp, переключил на tcp - все заработало. Ковыряться не стал. Причем до этого стабильно и долго работало, потом вот неожиданно стало как у тебя.

У меня простой советский OpenSSH.

а вообще информации нехватает. Неплохо-бы знать что за терминал используется, увидеть переменные TERM COLUMNS COLS в терминале и в сессии ssh. Выхлоп stty тоже не помешал-бы. И надеюсь ssh-сессия чистая ? Безо всяких mc, screen на концах ??

Про чистоту не совсем понял. На терминале ^M и подобного нету, если про это речь. Остальные данные:

$ echo $TERM
xterm
$ echo $COLUMNS
208
$ echo $COL

$ stty
speed 38400 baud; line = 0;
eol = M-^?; eol2 = M-^?;
-brkint ixany

автор говорит, что на той-же площадке ещё 5 его серверов, думаю что под тем-же дистрибутивом с тем-же софтом, поэтому варианты неправильно настроенной сети или сбойного ssh крайне маловероятны. Прям таки даже интерестно что это за такие «детские грабельки» :)

Дистрибутив везде Ubuntu, но на проблемной машине версия 11.04, на остальных более старые версии.

TCPMSS в iptables и STRACE попробую и отпишу еще чуть позже.

ps -ef|grep java > 1.txt

тоже виснет :-/

Преступник обнаружен

Через STRACE обнаружил, что ps -ef виснет на чтении cmdline одного из процессов: /proc/18745/cmdline. Попробовал сделать cat этого файла, тоже виснет, что логично.

Процесс этот - Apache Cassandra, запущенный на OpenJDK. На другой машине у меня работает Cassandra без проблем, но там Ubuntu другой версии.

нашел слабое место
UBUNDU

Вышли тот файл себе на почту и выложи тут. И какой-нибудь работающий вариант с другого сервера, если несложно.

Столкнулся с аналогичной проблемой. Также зависает на командах top и cat. Пробовал запускать в screen - без изменений. Системы Ubuntu и Debian.

Есть какие-нибудь мысли по этому поводу?

Сорри... Ветка не вся открылась. Можно удалить это сообщение и предыдущее.

Была проблема в libjna и CASSANDRA.