https://www.opennet.ru/openforum/vsluhforumID9/10334.html С год назад хотел организовать параллельное исполнение, но что-то не вышло, и я оставил всё на одном ядре. Очень медленно. Как лучше его сделать? Хотя бы без синхронизации (синхронизация фоновых жобов развлечение ещё то, не хочу городить грязь, где она не нужна).<br><br>Один. Нужно просто запускать ещё 1 процесс по процессу на ядро как только завершился предыдущий и пока есть работа.<br><br>Два. Нужно организовать вывод из всех скриптов, разделить экран по числу ядер в tmux или можно придумать что-нибудь ещё?<br><br>Жду ваших советов и предложений, спасибо.<br> https://www.opennet.ru/openforum/vsluhforumID9/10334.html#26 Mon, 12 Oct 2020 16:19:19 GMT Там задача была ждать данные в основном потоке и накапливать, валидировать, и сбрасывать на диск каждые N времени в дополнительном фоновом основываясь на ряде условий. Какой ещё крон? Использовать тут крон это напрашиваться на проблемы -- при убийстве скрипта некому будет его отключить. Полагаю, ваши скрипты очень грязные.<br><br>Но это не имеет никакого отношения к текущей проблеме. Сейчас меня интересует организация красивого вывода с индикацией работы скрипта (без ncurses). Простое "решение" у меня и так есть, это find . -name "*" -print0 &#124; xargs -0 -n 1 -P "$(nproc)" -I '{}' script '{}' однако вывод превращаеся в мешанину. "Классическое" решение это отключить вывод, но меня оно не устраивает.<br> https://www.opennet.ru/openforum/vsluhforumID9/10334.html#25 Mon, 12 Oct 2020 15:42:46 GMT Выдумываете себе проблемы, чтобы потом героически их превозмогать. Сраному скрипту в кроне - нужны данные о процессах уровня ядра! Линукс Торвальдс должен срочно сделать новые апи, чтобы вы смоги решить свои задачи...<br><br>Вам нужно запустить какие-то джобы в параллель и обработать их ошибки, если что-то пошло не так. Для этого не нужно никакого IPC при условии правильного проектирования.<br>Если не можете придумать, как это сделать без абсурдных переусложнений - наймите системного администратора. <br> https://www.opennet.ru/openforum/vsluhforumID9/10334.html#24 Sun, 11 Oct 2020 00:14:58 GMT Какая же гадость этот parallel. Он поддерживает вывод в tmux (казалось бы что ещё нужно!) но запускает при этом 100 раз одновременно и ломает вывод консоли. Ещё и наспамила в консоль своим бредом сначала, автор очевидный аутист.<br><br>Ну в принципе вот это наверное, да. Утянул себе нужное, надо закончить и посмотреть, как будет, а то xargs конечно нормально работает, но мешанина вывода совершенно нечитаемая. https://gist.github.com/mlgill/ad2693f17aaa720ef777<br><br> https://www.opennet.ru/openforum/vsluhforumID9/10334.html#23 Fri, 09 Oct 2020 19:32:00 GMT Проблема в том, что "системные утилиты, работающие с процессами", не могут предоставить информации, не имеющейся у ядра. А сканирование всех процессов на предмет ближайшего предка (если он ещё не потерян!) -- это не самое лучшее решение, подверженное всё той же гонке и случайным плавающим багам. Все мои попытки передавать сигнал по цепочке завершились тем, что в одном случае из десяти (или ста), процессы их игнорировали и успешно демонизировались. Перепроектировать логику не получится. Если тот же sleep запущен, он будет продолжать висеть под инитом, пока его не убьют, или он не закончится сам.<br><br>Вопрос был как организовать и перенаправить вывод в удобоваримом виде, а не как запустить несколько процессов параллельно. Вопрос, как принудительно завершать потомков при (внезапном) завершении мейна мы не рассматриваем, очевидно, что адекватного решения для него в интернете просто нет.<br> https://www.opennet.ru/openforum/vsluhforumID9/10334.html#22 Fri, 09 Oct 2020 18:56:54 GMT Пиды процессов внуков только через системные утилиты, работающие с процессами. <br>Либо вы шлете сигнал дочке, а она его обрабатывает, делая что-то с внуками. Но проще так не делать и перепроектировать логику.<br><br>Скрипт, который будет делать то, что вам надо, это примерно строк 10, может быть 20. В нем будут такие вещи, как for in, nproc, &, wait, возможно $!, trap. Отлично гуглятся все вопросы, которые могут возникнуть при написании. Во всяком случае, по-английски все документировано и разжевано.<br><br>Вам принципиально, чтобы какой-то русскоязычный васёк за вас скрипт написал? Фетиш какой-то? Уже два дня побираетесь, можно было уже пару раз перечитать доку по башу вдоль и поперек.<br> https://www.opennet.ru/openforum/vsluhforumID9/10334.html#21 Fri, 09 Oct 2020 18:01:10 GMT Форк ведь может переопределить дескрипторы для себя? Это никак не должно затрагивать родительский процесс.<br> https://www.opennet.ru/openforum/vsluhforumID9/10334.html#20 Fri, 09 Oct 2020 17:37:14 GMT &gt; В связи с чем вопрос. Можно ли как-то подцепить вывод форка себя <br>&gt; (и автоматом всех потомков форка) к шеллу, запущенному в панели tmux? <br><br>Так, допустим, можно перенаправить все три потока для каждого процесса в именованные трубы (не проверял ввод, но вывод определённо будет работать), т.е. нам как минимум всё ещё необходимо сохранить список дочерних процессов (может и работать, при условии, что те не будут рекурсивно форкать себя и терять потомков), но мы всё ещё подвержены состояниям гонки и неадекватной реакции на сигналы. Тут тут возникает вопрос с тем, что tmux сам по себе и он может обидеться, когда мы начинаем взаимодействовать с шеллом в обход него, т.е. у tmux надо как-то отнять контроль над выводом (вводом) запущенных им шеллов.<br> https://www.opennet.ru/openforum/vsluhforumID9/10334.html#19 Fri, 09 Oct 2020 17:06:21 GMT В связи с чем вопрос. Можно ли как-то подцепить вывод форка себя (и автоматом всех потомков форка) к шеллу, запущенному в панели tmux?<br> https://www.opennet.ru/openforum/vsluhforumID9/10334.html#18 Fri, 09 Oct 2020 16:49:50 GMT &gt; xargs + screen/tmux <br><br>Я вспомнил, чем мне не подошёл этот вариант. Там вроде бы можно было только отправлять команду на исполнение в панели, т.е. запуск новых процессов нонстоп (это то, что я использовал в конечном итоге, но тут это не подходит, хотя и можно набросать отдельный однострочник, запускающий этот скрипт -- мне как раз хотелось отказаться от по-файлового исполнения, слишком много времени на запуск уходит, особенно на "нелинуксе"). Либо добавлять текст (вывод) в панель уже после завершения, но нельзя было прицепить stderr/stdout/stdin запущенного процесса (и его потомков) к панели tmux и переключать его на вывод следующего процесса после завершения первого.<br>