Автоматическое убийство процесса через Htop и выполнение команды после

Мне вспомнилось что, когда «прибиваешь» процесс pulseaudio, она снова стартует. Как какой-то вирус.

Может всезнающие гуру знают, как это сделано?

Пишешь свою программу, мониторящую загрузку CPU процессом и перезапускающую его, htop не при чем.

Понимаешь, что критерий ужасен, так как убиваешь и при легитимной нагрузке.

Ищешь правильный критерий зависания, в процессе поиска и диагностики решаешь оригинальную проблему.

Пропускать шаги приветствуется.

Через socket activation или какой-нибудь dbus. Клиента pulseaudio какого-нибудь не прибил, сервис поднимается заново, все пучком.

Проблема XY. Причем тут htop?

Все вопросы в техразделах - проблема XY. Не умничай, следуй традициям: ты угадываешь X, ТС водит тебя за нос.

Знать бы еще как написать эту программу, я в линуксе полный ноль, пришел за помощью сюда.

Ну тогда давай может тогда в качестве исключения пойдём простым путем и ты сразу расскажешь проблему? =)

Да вроде все нужное рассказал, хотя, возможно, не с той стороны подошел и Htop не нужен. Нужна просто штука, которая следила бы за процессом, и в случае его краша/зависания выполняла бы определенную команду в определенной директории. Как мне показалось, Htop может с этой задачей справиться, поэтому по нему изначально вопрос и был задан. Но мб и без него все можно сделать.

Нет. Давай я за тебя начну: «проблема в том, что один процесс идет вразнос».

Теперь рассказывай, что за процесс, при каких условиях.

Не умничай, следуй традициям: ты угадываешь X, ТС водит тебя за нос.

Лучше прикинуться шлангом и ответить на вопрос буквально, пусть ТС сам вертится

Источник выделенного сервера или SRCDS (Source Dedicated Server) - это инструмент, который запускает серверный компонент игры Source без клиентского компонента. Другими словами, он имитирует игру, не рисуя ее. Простыми словами - сервак по игре Garry’s Mod. У него есть свойство зависать или крашиться из-за каких-то внутриигровых ошибок, это может быть банальный спам пропами или луа-ошибка, не так важно. В принципе, зависание можно отнести к крашам в том числе, т.к. после них сервер (процесс SRCDS) неживой в любом случае. Правда, если сервер прям упал (крашнулся), то он должен авторестартнуться без какой-либо помощи, но как правило он именно зависает и не авторестартится, хотя и после крашей он не всегда встает, в общем-то. В общем, для этого процесса это норма, он себя так и должен вести. Полностью избежать крашей невозможно, рано или поздно он все равно случится. В общем-то, краши/зависания - это полбеды, другая проблема в том, что он после них не встает. Не знаю даже что еще тут добавить.

Ниче в этом не шарю, но ладно. Допустим у тебя действительно неисправимо кривой сервер и ему нужен мониторинг. Клиент у тебя есть от этого сервера? Почему им не мониторить?

Понимаешь, что критерий ужасен

Ищешь правильный критерий зависания

+1. Мне для написания watchdog’ов помогла эта статья: https://habr.com/ru/post/209446/

Мне вспомнилось что, когда «прибиваешь» процесс pulseaudio, она снова стартует. Как какой-то вирус.

ты ж ленивая жопа :)

router@calypso:~$ systemctl list-unit-files -a --user | grep -i pulse
pulseaudio.service                    disabled
pulseaudio.socket                     disabled

router@calypso:~$ systemctl status --user pulseaudio.service
● pulseaudio.service - Sound Service
   Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-02-22 22:32:02 MSK; 5h 20min ago
 Main PID: 1308 (pulseaudio)
   CGroup: /user.slice/user-1000.slice/user@1000.service/pulseaudio.service
           └─1308 /usr/bin/pulseaudio --daemonize=no

router@calypso:~$ less /usr/lib/systemd/user/pulseaudio.service
[...]
[Service]
[...]
Restart=on-failure
[...]

Он ещё до появления systemd перезапускался.

Только не помню уже, через сессионную dbus, или напрямую клиентской библиотекой через запуск бинарника.

Если есть клиент с исходниками, самое очевидное решение - собрать специальную версию клиента, которая просто коннектится и возвращает статус, ответил сервер или нет.

Держать запущенный скрипт, который раз в N минут проверяет этим клиентом состояние сервера и перезпускает при необходимости.

Как минимум потому, что я даже не знаю что это за клиент, где его взять и что он из себя представляет.

я урью тибя лодочнег

Можно этот вопрос обсудить как-то лично? Например, в дискорде? Там человек, который хоть что-то понимает в этом, лучше объяснит что к чему. Смогу даже заплатить чем-то, если как-то поможешь.

Первая строчка в гугле (хотя не обязательно решать задачу именно так, вариантов много) https://askubuntu.com/questions/553110/how-to-automatically-restart-an-applic...

Не со мной, мне неинтересно. Я просто хочу, чтобы ты бросил идею мониторить именно загрузку и нашёл что-то другое. Если он, допустим, перестаёт принимать TCP-соединения, то это уже гораздо лучше критерий. Погугли «мониторинг чего-у-тебя-там». Ну или создавай тред в Job, с ценником и требованиями,максимально близкими к желаемому результату (а не твоему виденью пути к его достижению).

Я просто хочу, чтобы ты бросил идею мониторить именно загрузку и нашёл что-то другое.

Для его задачи на текущем это нормальная идея. Неправильная, но вполне подходит.

Откуда уверенность, что CPU usage не упрется в потолок, ну, не знаю, сразу после рестарта например? Или при нормальном использовании.

Согласен. Поэтому предлагаю рестартить процесс по крону каждые 4 минуты, способ верный

Нужно сделать такую вещь, чтобы если процесс с заданным именем (в моем случае SRCDS) ест больше 99% памяти - его нужно принудительно убить, после чего за пользователя прописать команду: ./gmodserver st.

Нужна просто штука, которая следила бы за процессом, и в случае его краша/зависания выполняла бы определенную команду в определенной директории.

Есть такая утилита ps, у неё очень гибкое форматирование вывода, так что в сочетании со скриптингом на bash твоя задача должна быть не сложно решаемой.

Из его опыта ( владельца игрового сервера). Пример с so выше который скидывал я не проверял, но раз автор говорит что долгий жрач CPU - повод для ребута, пусть так и будет.

Это его желание и его задача. Что за мания для ру форумов объяснять автору его неправоту? Он задал конкретный вопрос - я ответил. Захочет разобраться нормально - напишет, попросит помощи.

Килять не сразу, как превысит 99%, а если будет жрать это дольше пяти минут. В чем проблема? Да, это кривое решение, но с левыми бинарями как ещё?

Мониторить предоставление / непредоставление сервиса.

Ему это дороже выйдет, чем рестарт, очевидно же.

Человек хочет выстрелить себе в ногу? Пусть учится скриптовать и стреляет.

Человек хочет решить задачу? Играем в игру "убеди человека решать задачу, а не че он там себе надумал.

Анон, за 20 лет на форуме мог бы заметить, что «решать» сформулированное в шапке невыгодно ни ТСам, ни нам.

Неочевидно. Вдруг у него в протоколе, например, сервер выводит баннер, и этого было бы достаточно.

Тебе может невыгодно, но я тут выгоды не ищу. Я поэтому и анон, что могу писать разные вещи и не набивать себе скор и политическую лояльность.

Тебе не нравится задача? Ок, не решай ее. Тебе не нравится мое решение? Ок, ничего страшного.

Просто пускать клиента и чекать валидность сервера выйдет сильно дороже. Надёжность и аптайм гейм-сервера не важны, раз он готов килять его по каждому чиху, так что решение очевидно.

Прими реальность, где все работает криво, косо и через жопу.

Надёжность и аптайм гейм-сервера не важны, раз он готов килять его по каждому чиху

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

Вся суть ру форумов, ты победил. Я был неправ.