У меня следующая проблема: многие пользователи создают сеанс VNC и после этого забывают о них. Через некоторое время эти сеансы вылетают и начинают потреблять около 100% энергии. Затем кто-то должен убить их вручную.
Мой вопрос: есть ли способ найти эти сбойные сеансы и убить их автоматически?
вы можете настроить задание cron на запуск каждые x минут сценария, который, по сути, запускает "ps aux | grep vnc", и для каждого экземпляра убивать pid, если proc util превышает определенный порог.
Вы можете запускать сеансы VNC из xinetd, который завершит работу vncserver, когда клиент отключится. У этого есть недостаток, заключающийся в том, что пользователи не могут закрыть свою программу просмотра и повторно подключиться позже.
Нужно ли вашим пользователям повторно подключаться к сеансам или их сеансы должны заканчиваться при отключении? Если им не нужно повторно подключаться, ответ Джеффа МакКьюна - хороший подход. Если им действительно нужно переподключиться, я бы предложил поискать в выводе netstat -an любые порты VNC, которые слушают, но не имеют установленных соединений. Затем для этих портов вы можете найти в выводе «ps ax» идентификатор процесса соответствующего номера экрана VNC и поместить его в список. Наконец, вы должны пройти по списку и уничтожить эти PID.
Я не уверен, насколько возможно создать автоматизированное решение, которое не должно полагаться на эвристику и наблюдение / анализ различных бит / proc и / sys.
Я / мы используем RealVNC (Xvnc) на RHEL4, а бесплатная версия RealVNC имеет тенденцию делать то, что вы описываете (я еще не видел, чтобы коммерческий / платный RealVNC делал это). Кажется (у меня нет ничего лучше анекдотов для подтверждения этого), что для нас это взаимодействие между (древним) gnome / metacity и Xvnc, которое иногда вызывает это, поскольку я убедил некоторых пользователей переключиться на XFCE, а они не сделали этого. т с тех пор обеспокоен этим.
То, что я сейчас делаю (быстрое и грязное решение), - это магия python, которая ищет процессы с / proc / <pid> / exe, указывающие на двоичный файл Xvnc, анализируя файлы журналов, на которые указывает fd 2, процессами чтобы определить, сколько времени прошло с тех пор, как пользователь фактически использовал сеанс (и в случае удаленного файла журнала, предположить запуск процесса и уведомить как таковой), а затем завершить процессы Xvnc, которые не использовались в течение нескольких недель.
Что я собираюсь сделать, так это сделать это немного более отслеживаемым, время от времени выбирая / proc / <pid> / stat для поиска процессов Xvnc, которые поддерживают увеличение времени utime близко к времени стены в течение более длительного периода времени, и используют это как вместо этого моя эвристика.
В идеале я хотел бы найти первопричину этого, но из-за отсутствия времени (и желания) погрузиться в нутро Xvnc я в настоящее время просто облегчаю симптомы.
Выход или остановка сеанса VNC 1. Чтобы выйти из сеанса VNC, просто закройте клиентское окно на своем локальном компьютере. Это прервет ваше соединение с сервером VNC, но оставит сеанс VNC-сервера нетронутым, чтобы вы могли подключиться к нему позже.
2. Чтобы завершить сеанс VNC-сервера, войдите в систему melodic и введите следующую команду: runvnc -kill: xx, где xx - номер вашего дисплея.
3. Если вы забыли номер вашего дисплея (или чтобы проверить, сколько сеансов VNC-сервера вы можете запустить), введите ps ax | grep Xvnc Команда 'ps' сгенерирует список запущенных вами процессов. '|' sign будет "перенаправлять" вывод команды ps команде 'grep', которая будет искать и отображать те строки, содержащие выражение "Xvnc". В этих строках вы увидите Xvnc, за которым следует: x, где x - номер вашего дисплея. Xvnc - это процесс unix, который запускает сеанс VNC-сервера. Теперь, когда у вас есть отображаемый номер, вы можете либо завершить сеанс Xvnc, либо подключиться к нему со своего клиента VNC.
Вы можете еще больше сузить список процессов Xvnc, чтобы отображать только свой, набрав
пс топор | grep Xvnc | grep
где ваш логин.