как определить какой процесс отвалился?

перевернуть» всё и использовать очередь задач.

мне кажется это сложнее лапши на баше

мне кажется такой while на 5000 процессах будет грузить всю систему

Грузить чем? Если твоя программа вылетает каждую микросекунду, то такое решение действительно неоптимальное, но если у тебя проги работают часами – норм.

а нельзя что-то наподобие

for dir in dirs
./runner $dir&

cd $1
while 1:
  {
   ./program
    wait -n
   } 

попробую завтра вникрунть в тот пример

systemd-run

там примерно так и есть

только проблема отслеживания живучести бинарника из каждой директории это же не решает

перезапускалка:

Дык у мну такая же…

в смысле не решает? wait ждёт завершения и только после этого делает повторный запуск

А зачем wait в runner?

ждёт завершения запущенной программы.

Если что я там код возврата проверяю. Тип если программа вернула 0, то перезапускаться не будет. Если тебе нужно реально вечный цикл, пиши while true.

Дык он так и так ждёт:

[r2-d2 ~]% cat wait.sh 
while true ; do
    sleep 1 && echo "AA"
    wait -n
done
[r2-d2 ~]% bash wait.sh 
AA
AA
AA
^C
[?130 ~]% cat no-wait.sh 
while true ; do
    sleep 1 && echo "AA"
done
[r2-d2 ~]% bash no-wait.sh 
AA
AA
AA
AA
^C

Ну если ты запускаешь в фоне с &, то ничего ждать не будет. А так можно после повторного запуска, если в фоне запуск можно что-то сразу сделать - вывод сообщения о перезапуске итд и потом wait -n.

Твоя его не проняла.

Ну если ты запускаешь в фоне с &, то ничего ждать не будет.

Только что попробовал запустить свой no-wait.sh — нормально всё ждёт. Ты ж запускаешь в фоне не саму прогу, а runner.

Слишком сложная :(

а
интересная идея

Знаешь, что еще ждет завершения?

Отсутствие wait.

ты сегодня хорош

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

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

ссылки с лишними символами %22

Ну так прогони полный пузинг

Делов-то

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

В общем — да, все осмысленней, чем твой ...; wait. Но ТСа надо сначала вывести из трех сосен, потом достраивать остальной лес.

некоторые процессы там в списке отсутсвуют

От того, что процесс перезапустит себя, его имя не должно изменяться. Если у вас процесс делает что захочет — меняет имя, рабочий каталог и т.д., то только запускать каждый процесс от отдельного пользователя/группы/chroot'а/cgroup'ы. Но если эти ваши процессы ещё должны от root работать, то вобще не знаю.

, хотя они запущены и работают 100%

Как определяется, что процесс запущен и работает?

monit, ёпрст.

Пиши для каждого systemd unit, там есть перезапуск при падении

спасибо
интересно

что такое полный пузинг

велосипедить на баше всяко веселее и проще
чем икать причины падения приложения на с++

тс попробуем решить задачу просто


while

./ тут что-т запускаем

по идее если оно упадёт
оно же само перезапустится да и всё

От того, что процесс перезапустит себя, его имя не должно изменяться

имя нет, насчёт pid не уверен

но я вообще не понимаю, почему эти тулзы не показывают, что процесс жив, не показывают pwd
самое страннное, что такое поведение на 10-20 процессах из тысяч
вообще не понимаю, что происходит

Как определяется, что процесс запущен и работает?

на него можно подать входные данные и он выдас выходные

monit сложнее лапши на баше

уже обсудили такой подход

как бы бы запускал 5000 одинаковых процессов с одинаковым именем и отлеживал бы их активность?

я б запускал через скрипт-обертку: как только процесс упадет, скрипт получит управление взад и может применить логику – написать в логи, бибикнуть пищалкой, и, внезапно, перезапустить процесс

мне кажется такой while на 5000 процессах будет грузить всю систему

ни единого такта впустую не потратит: тут же блокирующий вызов ./test

Если упадёт systemd, упадёт ядро.

Плохой, плохой системдэ! :)

вот, а если упадет своя писулька на баше – даже энтропия не повысится!

ура

systemd умеет регистрировать сегфолты

а если их будет 5000 - как предлагаешь их запускать

критикуешь - пердлагай
как бы бы запускал 5000 одинаковых процессов с одинаковым именем и отлеживал бы их активность?

По-нормальному - я бы написал обёртку (одну) на Си, которая сама делает fork(), execve(), wait(), при необходимости сканирует /proc для получения списка процессов включая полные пути к их бинарникам, в итоге ведёт список процессов - тех которые должны быть запущены и тех, которые реально запущены. Вобщем-то даже делал похожее.

Запускалка должна сохранить в файл с именем в виде nnn.pid параметры запуска, где nnn - pid запущеного процесса.

Можно мониторить завершение любого процесс (через netlink). https://bewareofgeek.livejournal.com/2945.html

(Нужно чуть подправить)

Если pid завершенного процесса есть в списке, то запустить его с указанными параметрам, а файл nnn.pid переименовать в pid вновь запущеного процесса.

энтропия повышается от моего треда на лоре

предлагаешь 5000 юнитов писать с авторестартом?

Там есть такая штука, как shit@dirX.service. Один юнит, 5000 симлинков.

энтропия повышается от моего треда на лоре

А че я? Я искренне поддерживаю твое желание навелосипедить на баше: пошли они в жопу со своим систем дэ – уже скоро каждый блин cd и cp надо будет делать через систем дэ.

Хотя, конечно, правильный путь (но не самый легкий) – исправить падение в основной программе, но одно другому не мешает

Если имя процесса не изменяется, то он должен быть в выводе pgrep. Начните сравнивать, типа вывод ″pgrep″ в файл. Потом вывод ″ps ″ в файл, ″grep″ по файлу с вывода ps, sort, diff, чтобы убедиться, что ″pgrep″ работает корректно...

А за конструкции:

pwdx $(pgrep -f some_prosees_name)

Плюс, тут проблема, что между тем, как ″pgrep″ выдаст pid и тем, как ″pwdx″ полезет в ″/proc/PID″ проходит заметное время, за которое ваш процесс может перезапуститься. Может нужно как-то читать /proc/PID/cmdline и /proc/PID/cwd почти одновременно, а потом фильтровать вывод.

Если у вас каждый процесс запускается отдельным бинарником (по копии на каталог), то можно смотреть /proc/PID/exe как-то так:

find /proc/ -maxdepth 2  -name exe  -printf '%h %l\n' 2>/dev/null

спасибо
вы навели меня на верную мысль

Если имя процесса не изменяется, то он должен быть в выводе pgrep. Начните сравнивать, типа вывод ″pgrep″ в файл. Потом вывод ″ps ″ в файл, ″grep″ по файлу с вывода ps, sort, diff, чтобы убедиться, что ″pgrep″ работает корректно...

таки да, всё работает корректно, просто моя логика была некорректная, я почему-то подумал, что pgrep всегда отдаёт данные в алфавитном порядке...

между тем, как ″pgrep″ выдаст pid и тем, как ″pwdx″ полезет в ″/proc/PID″ проходит заметное время, за которое ваш процесс может перезапуститься. Может нужно как-то читать /proc/PID/cmdline и /proc/PID/cwd почти одновременно, а потом фильтровать вывод.

там вроде pgrep и pwdx мгновенно отрабатывают, процессы так часто не перезапускаются, я просто в своей лапше опирался на непровереное поведение, которое сам себе придумал)

я гарантирую это.

ты оказался прав
я нашёл в чём было дело
для этого понадобилось 100 комментов на лоре

твое желание навелосипедить на баше

всё решилось добавлением 5 букв в односторонник на баше

вот что сон животворящий делает