stdout через ssh проблема

добавь к параметрам tar в обоих случаях ключ v. Будет видно, какие файлы обрабатываются

ssh -Tt

добавил, ни на что не ругается, порядок при упаковке и распаковке разный, от diff глаза разбегаются в разные стороны. По количеству строк одинаково. Визуальных несовпадений нет.

попробую, немного отстаю в матчасти, могли бы объяснить что это дает? скрипт был написан до меня, давным давно забытым админом, честно говоря не понимаю для чего здесь -T

может лучше поспать? Если после «tar xvf some.tar.gz» выведенный список файлов отличается от видимого в файловой системе - это уже бредом попахивает. После отдыха проверь пробелы и "-" в вводимой команде, может там косяки.

man ssh ::)

 -T      Disable pseudo-tty allocation.

     -t      Force pseudo-tty allocation.  This can be used to execute arbitrary screen-based programs
             on a remote machine, which can be very useful, e.g. when implementing menu services.  Mul‐
             tiple -t options force tty allocation, even if ssh has no local tty.

Не от выведенного в системе, а от вывода с -v. В том то и дело что пропадают периодически. Пробелов нет, есть только «точки». Это файлы вида name.xxx.xxx.xxx.xxx.conf

Читал, по идее здесь не должно быть критично. Думал над тем что на вторую машину криво приходит. Но как бы скрипт работал годами и тут такой сбой. Там ~500 файлов конфигов dhcp, ими подменяется текущие (причем перед заменой старые вычищаются rm -rf). При отсутствии dhcpd падает, было б подобное ранее точно заметили бы)

Экстремальный скрипт. Ведь если ssh оборвётся, не все файлы распакуются. Когда я писал что-то подобное, то по ssh передавал не выхлоп tar'а, а именно файл, чтобы была известна md5sum, а на удалённом сервере сначала проверял md5 архива, и только потом распаковывал его.

Не проверял как это завязано с -T и -t, но ssh это не та штука которая может бинарные файлы через консоль тягать. ESC последовательности. ~., например рвет сессию.

Тебе нужен scp и это будет правильно. Запаковал, передал, распаковал.

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

Тут уже наверно больше принципиальный вопрос, что стало причиной. Ведь работало же)

ssh нормально обрабатывает tar на stdout. Это стандартная функциональность. Добавте в ssh ключ -v и измените команду:

cd $tempdir ; tar -xf -

cd $tempdir && tar -xf -

Так ну в общем-то варианты решения есть, спасибо всем! Хотелось бы услышать причину, почему стало так происходить.

Таки нашел проблему... и таки да это потери... Между серваками находится гейт на таком же линуксе. Файлы пропадают когда гейт нагружает zebra. Спасибо команде mtr)

И в итоге проблема была не в потерях, а в том что скрипт был прописан в cron в двух местах.

Кстати забавно, спасибо за итог.