Kill defunct xrdp session --- пользователи xrdp не могут войти в систему
Пользователь не может подключиться к серверу через xrdp, протестированный с помощью удаленного рабочего стола linux, а также клиента удаленного рабочего стола Windows
сообщение об ошибке "ошибка: проблема с подключением"
/var/log/sesman.log
показывает эту ошибку
[20170419-22:06:02] [INFO ] scp thread on sck 7 started successfully
[20170419-22:06:02] [INFO ] ++ reconnected session: username test,
display :47.0, session_pid 2869, ip xxx.xxx.xxx.xxx:53732 - socket: 7
Грэп для этого процесса
root@server:/etc/xrdp# ps -aux | grep defunct
root 2869 0.0 0.0 0 0 ? Z 19:08 0:00
[xrdp-sessvc] <defunct>
пытаясь убить процесс
kill -9 2869
не убивает процесс
как мне убить этот процесс?
пользователи не могут войти в то, что файл журнала говорит, что это существующий сеанс
однако при запуске посмотрите, чтобы увидеть отключенные сеансы TCP (не установленные соединения, а просто прослушивание портов), я не вижу ни одного сеанса, существующего для этого пользователя
это хроническая повторяющаяся проблема, которая, кажется, не проявляется ни в какой регулярной модели
А что я могу сделать?
список всех сеансов XRDP
#!/bin/bash
# find disconnect RDP sessions
lsof -b -w -n -c /^Xvnc$/b -a -iTCP:5900-5999
не показывает отключенные сеансы (все соединения TCP установлены для всех подключенных пользователей)
3 ответа
xrdp ведет дневник сеанса внутри файлов .xrdp*, хранящихся в домашнем каталоге пользователя. Может случиться так, что некоторые файлы сеансов .xrdp* будут сохранены в /tmp/ или /tmp/.xrdp/. Служба xrdp устанавливает связь с файлами этого сеанса. Итак, чтобы снова установить соединение при наличии несуществующих процессов, у вас есть три варианта:
- установить новое соединение с другим разрешением (работает как обходной путь, но я не рекомендую это делать)
- чтобы удалить файлы .vnc/sessman* из домашнего каталога затронутых пользователей, файлы xrdp* в /tmp и /tmp/.xrdp/ для затронутого пользователя и снова подключиться. (рекомендуемое решение)
- перезапустить службу xrdp, которая устранит корреляцию с файлами сеанса. (рекомендуется только в том случае, если вы можете позволить себе простои сеансов xrdp :))
Для любого, кто сталкивался с этой проблемой, я обнаружил, что сервер xrdp хранит некоторую информацию о состоянии отключенных сеансов. Даже анализ всех соединений TCP и уничтожение прослушивающих, но не установленных портов не решает эту проблему (хотя это решает огромную проблему ненужного распределения ресурсов).
Я обнаружил, что не могу пожать зомби и заставить XRDP создать новый сеанс, вместо того, чтобы пытаться повторно подключиться к предыдущему состоянию, без перезапуска сервера XRDP.
Единственная хитрость, которую я нашел, - это изменить разрешение экрана клиента, чтобы обмануть сервер xrdp, заставив его думать, что это новая машина. Это позволяет соединению быть принятым и устанавливает новый сеанс.
Немного поздно в игре, но почему это происходит, я не уверен, но на моем сервере с временем безотказной работы всего 7 месяцев были тысячи неработающих процессов xrdp. Я очищаю его с помощью "sudo systemctl restart xrdp.service".