-bash: 09,39: command not found

Это вы уже почти месяц так живёте? С учётом темы на http://debianforum.ru

Вобще копировать советуют с опциями -a, то есть ″--preserve=all″, а не ″--preserve=mode,ownership,timestamps″

Я бы посоветовал просто в начало и конец каждого файла инициализации (~/.bashrc и т.д.) воткнуть свою echo-строку, чтобы было видно, хотя бы в каком файле вылазит ошибка. То есть в начало ~/.bashrc добавить ″echo START .bashrc″, а в конце ″echo END .bashrc″.

Да. Именно столько и живу. Сообщение мое. Спасибо за совет. А копировал именно с опцией a.

После того, как определите проблемный файл, из остальных echo убираете, а в этот добавляете echo с разным текстом, чтобы чётко определить какая стока в этом файле приводит к выводу сообщения об ошибке.

А это разве не ваша фраза:

При копировании каталогов использовал cp -pri в соответствии с нагугленой инструкцией.

P.S. Надеюсь вы хоть чуть-чуть представляете что из себя представляет bash-cкрипт, допустим что комментарии начинаются с символа ″#″.

сделай

bash -x -c "source ~/.profile"
bash -x -c "source ~/.bashrc"

Прошу прощения.

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

Судя по всему выдается во время выполнения /etc/profile

Там из /etc/profile вызывается /etc/bash.bashrc и все файлы по маске /etc/profile.d/*.sh .

Да. Там присутствует один файл bash_completion.sh Это как я понял сборщик мусора PHP содержимое

# /etc/cron.d/php5: crontab fragment for php5
#  This purges session files older than X, where X is defined in seconds
#  as the largest value of session.gc_maxlifetime from all your php.ini
#  files, or 24 minutes if not defined.  See /usr/lib/php5/maxlifetime
echo comp 1
# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^

^@^@^@^@^@^@^ - Похоже на примешанный мусор. его удаление как-то ничего не помогает. Ошибка сохраняется. Судя по всему баг в строчке выше

Да, ^@ в этом файле это мусор и его там быть не должно. Только этот файл должен находиться под именем /etc/cron.d/php5 и никакого отношения к автодополнению в bash'е (bash_completion.sh) он не имеет.

Я очень редко видел подобные сбои файловой системы, с помощью cp их добиться невозможно.

FS - EXT4

Как проверить и исправить? Тут я как-то не ас. Но в целом система как-то работает и особых нареканий нет :(

Честно говоря я не знаю, как вам такое исправлять. Когда содержимое отдельных файлов лежит под именами других, да ещё в них мусор, то как это определить то можно?

Ну в rpm-based дистрибутивах можно проверить контрольные суммы файлов, установленных из пакетов (для конфигов это бесполезно) и переставить битые пакеты. В deb- дистрибутивах, вроде, можно было сделать что-то подобное.

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

А в целом не понятно, как такое могло произойти у вас, я такое видел только при восстановлении ФС с умирающего диска или после приколов vmware.

А в целом не понятно, как такое могло произойти у вас

Ну копировал он с битой ФС.

Как проверить и исправить?

man fsck.ext4

не забудьте размонтировать (корень надо проверять с другого линукса).

ещё возможно поможет fsck -f. При этом ФС может и убить некоторые файлы.

Ну а вообще, проще всё стереть нафиг, и проверять железо. Скорее всего барахлит HDD и/или RAM. Возможно перегрев и/или БП.

А в целом не понятно, как такое могло произойти у вас

либо железо битое, либо ТС делал бекап по живому, либо ТС делал проверку без размонтирования. Возможны комбинации и/или другое рукожопие.

Вы правы насчет моего рукожопия и не только. Основная проблема в том что эта система крутится на ARM (Raspberry Pi). Вместо штатной SD карты (на ней оставил только boot) - для ОС используется HDD. Да судя по всему поступил не правильно и копировал все по живой.

Попробую аналогично собрать debian в виртуальной машине и сравнить часть конфигов.

Не подскажите чем можно делать бекап на лету и отправлять его к примеру на яндекс диск?

либо ТС делал бекап по живому

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

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

Я безуспешно пытался допытаться, что именно делал ТС и, главное, зачем. Ваша очередь :-)

Странная битость ФС, от начала # /etc/cron.d/php5: до конца строки -delete верная информация. Размер 576 байт. У ext4 блок обычно 4 кбайт. Получается, что-ли, что ext4 при выделении нового блока под файл не зануляет его, а оставляет после конца файла старое содержимое?

да. этим занулением всегда XFS ругали

Получается, что-ли, что ext4 при выделении нового блока под файл не зануляет его

ну наверное быстрее записать один сектор (512б), а не все 8.

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

ну если командой dd, то может.

PS: вчера не посмотрел очередную серию сериала: смотрел с флешки в FAT, на которую корректно скопировал, но которую вынул ДО окончания umount. В результате серия X записалась наполовину. 20 минут X, потом Y/X вперемешку. Y — это та серия, которая была там раньше.

А ты говоришь — не бывает. С кривыми руками ВСЁ бывает.

Да, один сектор 512 байт, а там 576 байт информации, а потом мусор. Причём, файл явно создавался/записывался разом при установке дистрибутива, это не лог, который постоянно дописывается.

Получается, что ext4/ядро сначала считывает сектор, а потом пишет туда хвост файла. В случае данного файла был записан сектор 512 байт, а следущий сектор был считан и записан, чтобы в нём было 64 байта полезной информации и 448 байт старых данных, а не нулей. Это меня и удивило.

ну если командой dd, то может.

Вот здесь вот http://debianforum.ru/index.php?topic=6445.0 ТС заявлял, что копировал командой ″cp -pri″, а в этом треде, что использовал у ″cp″ опцию ″-a″.

С кривыми руками ВСЁ бывает.

Да, бывает. И что хуже, кривым рукам зачастую сопутствует кривая память и язык, так что невозможно точно узнать что именно делали эти кривые руки :-)) (Это просто наблюдение, а не попытка 5.2.)

а не нулей

я может неправильно тебя распарсил, но ^@^@^@^@ - это как раз нули. В генте такое в /var/log/messages сыпется, бага syslog-ng. пишутся бинарные нули и файл становится двоичным.

thecloneofmyown neverloved # file /var/log/messages
/var/log/messages: data
thecloneofmyown neverloved # cat /var/log/messages | grep -i error
Двоичный файл (стандартный ввод) совпадает
thecloneofmyown neverloved # cat /var/log/messages | strings | grep -i error
Jul 31 19:28:19 localhost /etc/init.d/lm_sensors[2732]: ERROR: lm_sensors failed to start

При просмотре в nano как раз такая же фигня -

Aug 3 11:19:37 ^@^@^@^@^@^@^@^@^@^@^@

Получается, что ext4/ядро сначала считывает сектор, а потом пишет туда хвост файла. В случае данного файла был записан сектор 512 байт, а следущий сектор был считан и записан, чтобы в нём было 64 байта полезной информации и 448 байт старых данных, а не нулей. Это меня и удивило.

скорее не ядро/фс, а само устройство.

Да, бывает. И что хуже, кривым рукам зачастую сопутствует кривая память и язык, так что невозможно точно узнать что именно делали эти кривые руки :-)) (Это просто наблюдение, а не попытка 5.2.)

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

я может неправильно тебя распарсил, но ^@^@^@^@ - это как раз нули.

дело в том, что «мусор» это часто — нули. Например ненужное место в файлах так забивают. EXT4 в курсе, не хранит и не копирует такие блоки (man cp, sparse). Но в данном случае ext4 тут не причём.

Да, точно это нули, а уже у меня mc головного мозга :(. Привык, что в Midnight Commander'е все непечатные символы выводятся точками. А ведь less, nano и т.д. выводя по-другому.

В следующий раз не буду играть в телепата и что-то измышлять без вывода hexdump.