Ematten
скрипт делает бэкап 12 Тб информации в мелких файлах на локальные диски и по сети через ssh. Благодаря тому, что rsync умеет отслеживать изменения перед копированием, это существенно ускоряет процесс и снижает расход трафика.

И что, ты это всё читаешь с экрана потом? Так что направь вывод с rsync в файл.

Потом добавь код такой, который этот файл вывода проверяет на изменения каждые десять секунд. Или там добавь код, который отслеживает процессы rsync в системе. Три процесса там, разделяющие между собой работу. Когда они исчезают, можно выводить текст на экран. Хотя зачем он нужен на экране для двенадцати терабайт? Кто его будет читать такой?

А можешь вообще сделать скрипт на Shell'е, который всё это контролирует, а потом из кода на питоне запускать только этот скрипт. Аргументы ему можно сделать, если у тебя из кода на питоне подаётся что-то разное каждый раз в rsync, скрипт будет просто брать эти аргументы и передать их rsync'у правильно. Но скрипт как раз будет работать столько, сколько надо, пока он там будет rsync в системе обнаруживать. Надо учесть, что rsync'ов в системе может быть несколько разных одновременно от разных задач, и один rsync от другого rsync'а надо тоже уметь отличать.

Ematten
Ни тот, ни другой вариант не работают

такой вариант как сработает?

по идее последующий код должен ждать когда вернется return_code.

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

А что говорит библиотека на которую я давал ссылку?

py.user.next, не понял вопрос. Что читаю? Вывод rsync? Нет, обычно он в non-verbose режиме. Для дебага включил его. По поводу вывода в файл и проверки: решение хорошее, если только мелкие файлы, а если там большой файл и все это по сети идет со скоростью 100 Кб/сек, то лог файл может не изменятся десятками минут. Так что отпадает. Я другой метод пока использую. Проверяю через psutil наличие процессов rsync с общим путем источника. Если они есть в течение 2 секунд при запросах каждые 0,5 секунд, значит процесс еще идет.

xam1816, тоже не работает.

ZerG, не смотрел потроха, но это вроде как обертка над вызовом системного rsync. Тоже не работает.

Богом клянусь ты делаешь что-то не так
Ситуация рядовая
Я 101 скрипт накатал для рсинка
И все пашет
У тебя рсинк выдает что0то свое так что предложение верное
лови процесс или месаджы от него и обрабатывай
Что-то не так в твоей системе

Ematten
По поводу вывода в файл и проверки: решение хорошее, если только мелкие файлы, а если там большой файл и все это по сети идет со скоростью 100 Кб/сек, то лог файл может не изменятся десятками минут. Так что отпадает. Я другой метод пока использую. Проверяю через psutil наличие процессов rsync с общим путем источника. Если они есть в течение 2 секунд при запросах каждые 0,5 секунд, значит процесс еще идет.

Короче, сделай внешний скрипт на Shell'е (это язык, который есть в Bash и других оболочках, которые соблюдают POSIX). Там используй программы ps, grep и так далее для отслеживания процессов. Там же запускай rsync. И вот скрипт на питоне просто запускает этот скрипт и снаружи подаёт в него пути что копировать, откуда копировать и куда копировать и всё. А дальше скрипт на питоне ждёт завершения этого чудесного скрипта, который и делает всю эту работу по обходу особенностей rsync'а. Таким образом всегда можно скрипту на питоне подать вообще другой скрипт, который тоже просто принимает пути, но в котором может вообще rsync'а не быть. Там может быть программа на Go, которая тоже так же берёт и сравнивает файлы, нужно ли их обновлять и может даже по сети копировать, но которая не форкает там ничего в системе и работает предсказуемо.

Нужно всю ерунду закрыть в чёрной коробочке и общаться с этой чёрной коробочкой просто снаружи. Это инкапсуляция в модуле и общение с этим модулем только через его интерфейс.