патченный bash & set -e, странное поведение

[sunjob]

добрый день

решил обновить BASH после "выхода в свет" недавно обнаруженной ДЫРЫ, точнее, присутствующей все время, и только недавно пристально обратившей на себя внимание

http://habrahabr.ru/company/mailru/blog/238475/
http://habrahabr.ru/post/238021/
etc...

патченный БАШ / bash - стал вести себя странно с оператором "set -e"
точнее, стал выбрасывать из скрипта по непонятным причинам, не смотря на то, что оператор, на котором происходил выход из скрипта - отрабатывал без ошибок

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

Код: Выделить всё

#!/bin/sh
clear; set -e
HOST=xxx.xxx.xxx.xxx
PTR=~/tmp/mnt_${HOST}
(
mkdir -p ${PTR}
sudo umount -l ${PTR} > /dev/null
)
sshfs root@${HOST}:/ ${PTR} -p XXXXX -o allow_other

# ...<blah blah blah> другие команды

$ mount | grep ${PTR}

сначала установил самый последний БАШ
bash-4.3.0 patch to 4.3.30

и заметил, что перестали нормально работать slackBuild-скрипты, которые раньше нормально отрабатывали

подумал, что навый БАШ непереваривает старые оси, ладно, установил заплаты на "свой родной баш"
bash-3.2.48 patch to 3.2.57

и та же самая история, slackBuild-скрипты перестали отрабатывать... доходят до команды make - и вываливаются, несмотря на то, что сама команда отрабатывает без ошибок

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

на десктопе такой откат - не существеннен, а вот на сервере...

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

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

...

slackware 12.2
kernel 2.6.32.63-smp
kde-tde 3.5.12

bash source
http://ftp.gnu.org/gnu/bash/

bash-3.2.48
with patches: bash32-049 - bash32-057

bash-4.3
with patches: bash43-001 - bash43-030

...

дополнение

основная проблема решена, остался один вопрос

>> видимо у меня наследование "set -e" в "Bashe" отключено
>> AFAIK зависит от дистрибутива.
как это "регулируется", ни кто не подскажет?

[Bizdelnick]

#/bin/sh

Во-первых, ! пропущен, во-вторых, если скрипт завязан на типичное только для bash поведение, то пишите

Код: Выделить всё

#!/bin/bash

Вы на 100% уверены, что /bin/sh у Вас - это bash?

P. S. Попозже поисследую поведение bash'а у себя.

[SLEDopit]

а сейчас вываливается из скрипта после команды монтирования

а вы не пробовали эту команду отдельно запустить и посмотреть exit code?
ну или отключить set -e и выводить exit code в скриптах?

[Bizdelnick]

Посмотрел на скрипт более внимательно.

Код: Выделить всё

mkdir -p ${PTR}
sudo umount -l ${PTR} > /dev/null

Если в каталог ${PTR} ничего не смонтировано (в том числе если он только что создан), то umount завершится с ненулевым статусом, и в случае set -e завершится и сам скрипт. Чтобы работало, как Вы хотели, надо делать как-то так:

Код: Выделить всё

sudo umount -l ${PTR} 2> /dev/null || true

[Bizdelnick]

Что могло измениться в bash - это наследование сабшеллом опции -e. Если Ваш скрипт раньше работал, значит, она не наследовалась (или /bin/sh был не bash, а другим шеллом, в котором в принципе нет такой опции). Теперь наследуется (у меня тоже).

GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
bash 4.2+dfsg-0.1+deb7u3

[sunjob]

1.
#!/bin/sh - правильно написано, конечно же была опечатка

2.
on slackware sh --> bash


3.

(
mkdir -p ${PTR}
sudo umount -l ${PTR} > /dev/null
)

эти строки взяты в скобки, раньше я думал (а собственно так и работало) что скобки
- сохраняют текущий каталог, при выходе из скобок
- не выбрасывают из скрипта, если внутри скобок произошла "ошибка"

и все время, пока я "писал скрипты" - "это правило" так и работала (да, собственно оно и сейчас так же работает, т.е. ошибка "umount" - не приводит к выходу из скрипта, скрипт далее работает, монтирует удаленную папку итд...

ошибку и выход вызывала далее идущая команда (я ее не показал в начале)

$ mount | grep ${PTR}

которая не была взята в скобки (далее вооще темная история)

дело в том, что вместе с башем был обнавлен и пакет
fuse-2.8.5
-->
fuse-2.9.3

все идущие следом за вер. 2.8.5 вт.ч. и последняя ver. fuse-2.9.3 - не показывавет точку
монтирования, точнее вывод точки монтирования в команде "mount" (если удаленный каталог был смонтирован с пом. "sshfs")

поэтому команда

$ mount | grep ${PTR}

ни чего не показывала, т.е. на этом мы и вываливались из скрипта

как только не крутил ключи конфигуратора, пересобирал, все равно не вернул "нормальное поведение" для "fuse" - точка монтирования не показывалась командой "mount"

ладушки, обновил, по рекомендациям сообщений конфигуратора "fuse"
util-linux-ng-2.14.1
-->
util-linux-2.19-i486

пересобрал все зависимости - итог, все равно fuse - не кажет точку монтирования

в итоге откатился до работающих версий

далее, как выяснилось большинство скриптов перестали работать из-за такого поведения команды "fuse-mount" (т.е. данная проблема решилась)

остались неск. скриптов, с непонятным "новым поведением", с ними разбираюсь (далее отпишусь)

появился новый вопрос:
КАК ВЕРНУТЬ ПРАВИЛЬНОЕ ПОВЕДЕНИЕ FUSE-MOUNT (т.е. что бы команда "mount" - нормально показывала смонтированный "sshfs" удаленный каталог)

спасибо за участие

[Bizdelnick]

эти строки взяты в скобки, раньше я думал (а собственно так и работало) что скобки
- сохраняют текущий каталог, при выходе из скобок
- не выбрасывают из скрипта, если внутри скобок произошла "ошибка"

Всё, что делают скобки, - это запускают то, что в них заключено, в отдельном сабшелле. Что там происходит с наследованием опции -e, из документации мне не понятно, но, как я писал выше, у меня на данный момент она наследуется.
Да, если нужно просто сохранить текущий каталог, более эффективно использовать pushd/popd.

все идущие следом за вер. 2.8.5 вт.ч. и последняя ver. fuse-2.9.3 - не показывавет точку
монтирования, точнее вывод точки монтирования в команде "mount" (если удаленный каталог был смонтирован с пом. "sshfs")

поэтому команда

$ mount | grep ${PTR}

ни чего не показывала, т.е. на этом мы и вываливались из скрипта

А покажите-ка ls -l /etc/mtab.

[sunjob]

$ ls -l /etc/mtab
-rw-r--r-- 1 root root 505 2014-11-13 19:41 /etc/mtab

$ cat /etc/mtab
/dev/sda1 / reiserfs rw,noatime,data=writeback 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
/dev/sda6 /home reiserfs rw,noatime,data=writeback 0 0
/dev/sda2 /mnt/hdd2 reiserfs rw,noatime,data=writeback 0 0
tmpfs /dev/shm tmpfs rw,noatime,size=8192m,mode=1777 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,noatime,mode=1777 0 0
tmpfs /var/lock tmpfs rw,noexec,nosuid,nodev,noatime,mode=1777,size=10m 0 0
root@192.168.0.251:/ /home/sun/tmp/mnt_192.168.0.251 fuse.sshfs rw,nosuid,nodev,allow_other,user=sun 0 0

это вывод с нормально работающим sshfs
т..е не понятно что должно было быть или наоборот...
поясните ваши подозрения или мысли

спасибо

p.s.
долго вспоминал, что где то проскакивала нечто связанное с "mtab"
проблема решена, короче, надо было
- установить новый "util-linux-2.19"
- пересобрать "fuse-2.8.5" с опцией разрешающей работу с "mtab"
- пересобрать "sshfs-fuse-2.5"

так что проблема с поведением "fuse" решена

осталось некоторое непонятное поведение баша с неск. скриптами
разбираюсь...

спасибо

Всё, что делают скобки, - это запускают то, что в них заключено, в отдельном сабшелле. Что там происходит с наследованием опции -e, из документации мне не понятно, но, как я писал выше, у меня на данный момент она наследуется.
видимо у меня наследование отключено

[drBatty]

$ mount | grep ${PTR}

к сказанному Bizdelnick'ом добавлю, что у вас mount работает в субшеле внутри другого субшелла. ССЗБ.

логичнее убрать скобки, и парсить /etc/mtab.

Код: Выделить всё

grep $PTR /etc/mtab

видимо у меня наследование отключено

AFAIK зависит от дистрибутива.

[Bizdelnick]

$ ls -l /etc/mtab
-rw-r--r-- 1 root root 505 2014-11-13 19:41 /etc/mtab

Так и думал: Патрику ещё никто не сказал, что сейчас в Европе и лучших домах Филадельфии принято вместо /etc/mtab класть симлинк на /proc/mounts. Видимо, последние версии fuse рассчитаны именно на такое поведение, и даже не пытаются что-то менять в /etc/mtab. Так что у Вас было два простых решения: или заменить /etc/mtab симлинком на /proc/mounts, или вместо вывода mount парсить непосредственно содержимое /proc/mounts.

- установить новый "util-linux-2.19"
- пересобрать "fuse-2.8.5" с опцией разрешающей работу с "mtab"
- пересобрать "sshfs-fuse-2.5"

Жесть как она есть...

[sunjob]

>> Патрику ещё никто не сказал
он умница и лучше знает что надо делать :о)
смотрите какая версия слаки у меня установлена (в актуальной версии, ск. всего все работате так как надо, в лучших и правильных дистрибьютивах...)

к стати:
$ cat /proc/mounts
...
root@192.168.0.251:/ /home/sun/tmp/mnt_192.168.0.251 fuse.sshfs rw,nosuid,nodev,relatime,user_id=1000,group_id=100,allow_other 0 0
...


>> Жесть как она есть...
жесть - это каждую неделю отслеживать обновления в дистрибьютиве и обновлять, обновлять, обновлять, актуализировать :о)
а по мне, раз в лет эдак 5-10 обновить что то ... это более чем не напряжно
все имхо

предлагаю, более не обмениваться мнением на форму, материал и цвета фламастеров
и говорить только ПО ТЕМЕ

спасибо за комменты

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

>> видимо у меня наследование отключено
>> AFAIK зависит от дистрибутива.
!!! как это "регулируется", ни кто не подскажет? !!!