SSH зависает. error: openpty: Нет такого файла или каталога ошибка: session_pty_req: session 0 alloc failed

Один из наших производственных серверов Ubuntu 14.04 перестал принимать соединения SSH. Когда мы пытаемся войти в систему, мы получаем текст баннера SSH, но затем он просто зависает. Если мы войдем в систему с помощью консоли управления, мы увидим следующие сообщения об ошибках в /var/log/auth.log[125 visibleUsing cat / proc / mounts | grep devpts; ls -hal / dev / {pts, ptmx} Я могу убедиться, что он существует и имеет правильные разрешения, и что нет никаких проблем с диском / индексным дескриптором:

devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0

crw-rw-rw- 1 root tty  5, 2 Oct  4 17:01 /dev/ptmx

/dev/pts:
total 0
drwxr-xr-x  2 root root       0 Aug 14 00:52 .
drwxr-xr-x 17 root root    4.3K Oct  4 17:01 ..
crw--w----  1 root tty  136, 18 Oct  4 17:41 18
crw--w----  1 root tty  136, 24 Oct  1 13:57 24
crw--w----  1 root tty  136,  3 Oct  4 17:39 3
crw--w----  1 root tty  136, 30 Oct  4 11:29 30
c---------  1 root root   5,  2 Aug 14 00:52 ptmx

df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            252G  4.0K  252G   1% /dev
    tmpfs            51G   53M   51G   1% /run
    /dev/sdi2       220G   13G  197G   6% /
    none            4.0K     0  4.0K   0% /sys/fs/cgroup
    none            5.0M     0  5.0M   0% /run/lock
    none            252G   12K  252G   1% /run/shm
    none            100M     0  100M   0% /run/user
    /dev/sdi1        75M   512   75M   1% /boot/efi
    /dev/md1        3.5T  282G  3.0T   9% /ssd

df -hi
    Filesystem     Inodes IUsed IFree IUse% Mounted on
    udev              63M   526   63M    1% /dev
    tmpfs             63M   725   63M    1% /run
    /dev/sdi2         14M  171K   14M    2% /
    none              63M     2   63M    1% /sys/fs/cgroup
    none              63M     1   63M    1% /run/lock
    none              63M     4   63M    1% /run/shm
    none              63M     4   63M    1% /run/user
    /dev/sdi1           0     0     0     - /boot/efi
    /dev/md1         224M    46  224M    1% /ssd

Я также проверил, что sshd_config соответствует другому серверу и имеет перезапустил службу ssh. Я считаю, что система devpty монтируется при запуске, но есть ли способ решить проблему без перезапуска сервера?

Я вижу https: //access.redhat. com / solutions / 67972 есть непроверенное решение этой проблемы в RedHat, но у меня нет доступа к подписке RedHat.

1
задан 5 October 2018 в 00:30
3 ответа

Я проверил другой работающий сервер и заметил, что параметры монтирования были немного другими:

Bad Server:  devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
Good Server: devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Я попробовал следующее, что позволило изменить разрешения на монтирование в соответствии с хорошим сервером:

sudo mount -o remount /dev/pts
sudo grep devpts /proc/mounts

devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Но я все равно получил те же ошибки при попытке подключения (даже после повторного перезапуска ssh).

0
ответ дан 3 December 2019 в 23:12

Я обнаружил, что могу заставить работать ssh-сеанс без tty, используя:

$ ssh username@servername /bin/bash -i

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
username@servername:~$ 

Я думаю, что в этом случае ожидается ошибка ioctl, потому что я начинаю интерактивный сеанс с чем-то, что нет терминала. У многих вещей есть проблемы в этом сеансе (TERM env var даже не задан), но я смог выполнить базовое устранение неполадок и обнаружил следующее:

#View a process list with parent process details
ps -axfo pid,uname,cmd | grep badservice | wc -l
27917

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

$ salt 'server*' cmd.run 'ps -aux | grep badservice | wc -l'
server.good:
    3
server.bad:
    27918

Скорее всего, это вызывало некоторую нехватку ресурсов, связанную с ptys. Неисправная служба была остановлена, и я убил все оставшиеся процессы для этого пользователя, используя sudo kill -u badservice . После этого SSH снова заработал как положено!

1
ответ дан 3 December 2019 в 23:12

У меня была такая же проблема, и она была вызвана тем, что я установил / dev с параметром - rbind в каталог другого компьютера, в который я хотел chroot .

mkdir -p /media/snapshot/
mkdir -p /media/test/
mount /dev/vg0/snapshot /media/snapshot/
mount /dev/vg0/test /media/test/
mount -t proc none /media/test/proc
mount --rbind /dev /media/test/dev
mount -t sysfs sysfs /media/test/sys
chroot /media/test/ /bin/bash
exit

Эти папки были смонтированы:

udev on /media/test/dev type devtmpfs (rw,nosuid,relatime,size=346156k,nr_inodes=86539,mode=755)
devpts on /media/test/dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /media/test/dev/shm type tmpfs (rw,nosuid,nodev)
mqueue on /media/test/dev/mqueue type mqueue (rw,relatime)

При размонтировании тома (в котором говорилось, что он все еще использовался) с параметром -l другие точки монтирования внутри / dev также были отключены:

umount -l /media/test
ll /dev/pts
total 0
drwxr-xr-x  2 root root   40 Mai 13 07:06 .
drwxr-xr-x 18 root root 4,1K Mai 13 07:07 ..

Обходной путь:

перезагрузите сервер, и все монтирования / dev будут воссозданы.

Решение:

с - bind вместо - rbind проблема не возникает:

mount --bind /dev /media/test/dev
0
ответ дан 13 May 2020 в 05:24

Теги

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