В чём разница между башом и программированием?

[amarao]

Dec 14 12:00:59 ubuntu dhclient[674]: Sending on Socket/fallback
Dec 14 12:00:59 ubuntu dhclient[674]: DHCPDISCOVER on ens3 to 255.255.255.255 port 67 interval 3 (xid=0x2ad36074)
Dec 14 12:00:59 ubuntu dhclient[674]: DHCPOFFER of 10.33.178.10 from 10.33.178.2
Dec 14 12:00:59 ubuntu dhclient[674]: DHCPREQUEST for 10.33.178.10 on ens3 to 255.255.255.255 port 67 (xid=0x7460d32a)
Dec 14 12:00:59 ubuntu dhclient[674]: DHCPACK of 10.33.178.10 from 10.33.178.2 (xid=0x2ad36074)
Dec 14 12:00:59 ubuntu audit[679]: AVC apparmor="DENIED" operation="exec" profile="/{,usr/}sbin/dhclient" name="/usr/bin/true" pid=679 comm="isc-worker0000" requested_mask="x" denied_mask="x" fsuid=0 ouid=0


Да-да. Была вот такая строчка:

md5sum "$mystatedir/isc-dhcp-v4-$interface" "$mystatedir/isc-dhcp-v6-$interface" "$mystatedir/ifupdown-inet-$interface" "$mystatedir/ifupdown-inet6-$interface" > "$oldstate" 2> /dev/null || true

В которой автор кода сказал "да, пожалуйста, игнорируйте любые ошибки в этом месте", но пришёл apparmor и сказал "нельзя, нельзя". И случилось чудное.

Программисты шутят про #define TRUE FALSE, а сисамдины отлаживают.

Comments

[amarao]

Разбирая вопрос архитектурно, ошибка находится в патологической связности (pathological coupling) между понятием "доступа к файлу" и значением внутри программы. Нет никаких внешних требований для того, чтобы true в языке программирования было привязано к существованию и выполняемости файла. Это кто-то когда-то придумал и в этот момент создал патологическую связь между работой программы и файловой системы.

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

Ошибка тут, как мне кажется, именно в этом. Доступность файловой системы предположена абсолютная, что напоминает требования к надёжности у старых кобольных программ - выдайте нам идеально работающий сервер с 100% аптайма и без единой ошибки когда либо (все ошибки пускай мейнфреймы устраняют за счёт аппаратной избыточности).

Более того, в баше не предусмотрено никаких аварийных процедур на этот случай.

[yurikhan]

Именно в баше (и dash’е) и именно для true предусмотрено:

$ type true false sed
true is a shell builtin 
false is a shell builtin
sed is /usr/bin/sed
$ PATH=/nonexistent /bin/bash -c 'true'; echo $?
0
$ PATH=/nonexistent /bin/bash -c 'sed'; echo $?
/bin/bash: line 1: sed: command not found
127

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

Также в принципе можно представить себе дистрибутив, который при загрузке создаёт RAM-диск и всё essential окружение живёт на нём, и в разумных пределах пофиг, что там отвалится или форс-размонтируется в процессе работы. Кажется, некоторые инсталляторы GNU/Linux’а так делают.

---

Доводилось мне видеть последствия отвала диска, на котором размещён своп. Байтораздирающее. Всё просто встаёт колом.

[amarao]

В свежих линуксах, кажется, даже не всё. Я был удивлён, но система отделалась несколькими сегфолтами.