Похоже, это блокер и лучше откатить правки, сделанные между 2.7 и 2.7.2,
а дальше уже разбираться -- теперь вот Лёня споткнулся об эти грабли,
пусть сам расскажет, как это именно выглядело у него.

Затрагивает и p9; в sisyphus_e2k откатил, в p9_e2k не успело добраться вроде.

Однако, остаётся удивительным факт, что это работает и не работает не всегда. Похоже, конечно, на рейс, но неясно -- между чем и чем. И, насколько я понимаю, есть ситуаци (например e2k) в которых стабильно не работает, но неясно -- с чем это связано.

(В ответ на комментарий №1)
> Похоже, это блокер и лучше откатить правки, сделанные между 2.7 и 2.7.2,
> а дальше уже разбираться -- теперь вот Лёня споткнулся об эти грабли,
> пусть сам расскажет, как это именно выглядело у него.
> 
> Затрагивает и p9; в sisyphus_e2k откатил, в p9_e2k не успело добраться вроде.

Так же блокером можно считать откат изменений. Другого удобного момента (такого как выход новых дистрибутивов и бранчей)  для перехода на симлинки /var/run и /var/lock еще долго не будет. А делать миграцию на уже установленных системах довольно тяжело и опасно. Поэтому лучше это сделать сейчас.

(В ответ на комментарий №3)
> (В ответ на комментарий №1)
> > Похоже, это блокер и лучше откатить правки, сделанные между 2.7 и 2.7.2,
> > а дальше уже разбираться -- теперь вот Лёня споткнулся об эти грабли,
> > пусть сам расскажет, как это именно выглядело у него.
> > 
> > Затрагивает и p9; в sisyphus_e2k откатил, в p9_e2k не успело добраться вроде.
> 
> Так же блокером можно считать откат изменений. Другого удобного момента (такого
> как выход новых дистрибутивов и бранчей)  для перехода на симлинки /var/run и
> /var/lock еще долго не будет. А делать миграцию на уже установленных системах
> довольно тяжело и опасно. Поэтому лучше это сделать сейчас.

Давайте попробуем локализовать багу, это действительно очень важно.

Мое наблюдение: бага возникает из-за того, что alteratord размещает свой socket не под /var/run а под /tmp. А это, в свою очередь (судя по коду alteratord) бывает когда он запущен не из под root.Вот почему это бывает - вопрос другой.
Еще видели странную группу у файлов - сuse. Что это?

(In reply to comment #1)
> Похоже, это блокер и лучше откатить правки, сделанные между 2.7 и 2.7.2
> Затрагивает и p9; в sisyphus_e2k откатил, в p9_e2k не успело добраться вроде.

Странно, что разница между alterator-pkg-2.7 и 2.7.2 как-то влияет на этот рейс. Он далеко и где-то совсем в другом. Зато в случае mike@ на Эльбрусе он проявляется хотя бы в логах. Вот он:

In unknown file:
   ?: 2 [request-unix-server "/var/run/alteratord/.socket" ...]

> теперь вот Лёня споткнулся об эти грабли,
> пусть сам расскажет, как это именно выглядело у него.

Думаю, баг один и это точно рейс, специфичный для конкретного железа, в моём случае его нет на p9 и на 8СП логи совсем иные, чистенькие, без единого подозрения. Хвост заканчивается ошибкой о том, что не найден шаг /grub. Лишь детальный анализ этих двух случаев говорит об ошибке не в общей логике, а чётко воспроизводимой проблеме на определённом железе, в большинстве же случаев баг не проявляется.

(In reply to comment #5)
> Мое наблюдение: бага возникает из-за того, что alteratord размещает свой
> socket не под /var/run а под /tmp.

В /tmp нет сокетов демона, там сокет клиента browser-qt.

> А это, в свою очередь (судя по коду alteratord)
> бывает когда он запущен не из под root.

Во всех случаях все процессы запущены из под root, проверил через ps.

> Еще видели странную группу у файлов - сuse. Что это?

cuse -- это на самом деле _alteratord:

ls -la /var/run/alteratord/.socket
... root cuse ...
grep cuse /etc/group
rpcuser:x:29:
cuse:x:483:
grep _alteratord /mnt/destination/etc/group
_alteratord:x:483

То есть, это GID 483 из целевой системы после выполнения в preinstall обратного bind-mount'а в /var/run/alteratord. Так оно выглядит в старых образах 8СП. На p9 всё наоборот, поскольку там новая история с /run и нет этого обратного монтирования, и там тоже имя группы в целевой системе не совпадает с именем в установочной системе, но в обратную сторону. Это значит, имеет смысл проверить на p9 после установки, какой группе будет принадлежать этот каталог.

(In reply to comment #4)
> Давайте попробуем локализовать багу, это действительно очень важно.

Думаю, будет непросто добраться до этой ошибки -- железку бы такую заиметь для начала. Но смысл баги после подключения strace'ом к разным PID'ам стал практически понятен. К слову, на p9 strace с libdw пришлось докладывать руками, strace надо бы в образ включить.

В случае проявления баги на 8СП, клиент обращается за очередным шагом к alteratord "по старому адресу" (сокету), тогда как новый alteratord в целевой системе ещё не успел его перекрыть или даже ещё не запустился. У mike@ на e2k это зафиксировалось в логе от _неизвестного файла_ guile. У меня на x86_64 это пришлось доказывать опытным путём. Шаги разделены чётко: начиная со steps_list до remount -- скрипты в установочной системе, все остальные -- в целевой.

Обращение к alteratord происходит в тот момент, когда...

- у mike@: сокет alteratord УЖЕ был удалён, но ещё не был перекрыт каталогом /var/run/alteratord либо альтератор там всё ещё запускался.
- у меня: сокет alteratord ЕЩЁ не был удалён, то есть, ещё раньше, а в установочной стадии шага /grub нет!

Немного разобрался в машинерии. Основной клиент -- guile-скрипт /usr/sbin/alterator-wizard создаёт в /tmp FIFO и работает через него в паре с /usr/bin/alterator-browser-qt. Независимо от происходящего в инсталляторе, примерно раз в секунду один запрашивает у другого авторизацию анонимуса и тут же получает положительный ответ. Иногда по этому соединению происходит более полезный в/в, но RAM точно не хватит, чтобы захватить весь strace.

Принципиальную разницу покажет фильтр по 'stat\(' и '/usr/share/alterator/'. Когда всё хорошо (у меня на p9), пути будут как в исходной системе, так и в целевой. Результат stat() не всегда положительный, но на каждый шаг один из четырёх запросов должен вернуть 0, иначе шаг не найден. Так вот на p9 вперемешку идут пути, которые иногда начинаются с /mnt/destination. А когда всё плохо (у меня на 8СП), ни одного такого пути нет, все обращения только в исходной системе. Последние четыре обращения в поисках шага grub, а его нет здесь.

И самый прикол: когда всё упало, запущено два alteratord, как и должно, сокет его доступен и там, и тут, обращение из исходной системы через alterator-cmdline к шагу /grub выводит корректный результат, мало того: повторный запуск инсталлятора приводит к его ругани о невозможности найти steps-list! Конечно, этого шага нет в целевой системе, ведь browser-qt работает теперь с новым альтератором.

compiled /tmp/.cache/guile/ccache/2.0-LE-8-2.0/usr/sbin/alterator-wizard.go -- похожие строчки у меня тоже были, но с другой версией. Грешу конечно на guile, исходя из точечности воспроизводимости, но судя по вышеописанной логике, там и без guile есть поводов для рейса.

В итоге: перевешивать на manowar@ или кто в этой машинерии лучше понимает, коммиты shaba@ реабилитировать, проверять свежие образы 8СП.

Предлагаю пока такой воркараунд:

diff --git a/alterator-preinstall/backend3/preinstall b/alterator-preinstall/backend3/preinstall
index a34822c..48423de 100755
--- a/alterator-preinstall/backend3/preinstall
+++ b/alterator-preinstall/backend3/preinstall
@@ -62,6 +62,7 @@ run_preinstall()
        done
 
        notify "package \" \" step $max"
+       sleep 2
 
        # replace itself with alteratord from chroot
        [ -n "${ALTERATOR_DESTDIR:-}" ] || return

Все предыдущие не помогли. Трассировка от mike@ проблему локализует однозначно.

(В ответ на комментарий №8)

> В итоге: перевешивать на manowar@

Можно, конечно. Но мне непонятен смысл слов

> На p9 всё наоборот, поскольку там новая история с /run

Что за история?

> и нет этого обратного монтирования

Кто-то убрал mount -o bind из backend3/preinstall ?

> Предлагаю пока такой воркараунд:
> +       sleep 2
>
> Все предыдущие не помогли.

А как же alterator-wait из того же самого скрипта? Он, по идее, обязан ждать, пока всё не станет как надо, а не 2 секунды.

(In reply to comment #10)
> мне непонятен смысл слов
> > На p9 всё наоборот, поскольку там новая история с /run
> Что за история?

Про симлинки /var/run и /var/lock, обсуждается в последнее время в devel@.
shaba@ и antohami@ лучше объяснят, по мне, так свежий тренд FHS. :-]

> > и нет этого обратного монтирования
> Кто-то убрал mount -o bind из backend3/preinstall ?

Пакет во всех репозиториях один и тот же.
На p9 это выглядит так (/var/run -> /run):

# ls -la /run/
... root _alteratord ... alteratord
# ls -la /var/run/
... root _alteratord ... alteratord
# ls -la /run/alteratord/.socket
... root 470 ...
# ls -la /var/run/alteratord/.socket
... root 470 ...
# chroot /mnt/destination /bin/bash
localhost / # ls -la /var/run/alteratord/.socket
... root _alteratord ...

То есть, в целевой системе всё пучком изначально. Это я перепутал в ночи. Здесь GID 470 не мапится на cuse или что-то ещё.

> А как же alterator-wait из того же самого скрипта?

Обязан, но не ждёт. Перезапуск инсталлятора после падения в моём случае с 8СП говорит о том, что alteratord в целевой системе запустился, то есть, alterator-wait должным образом не работает либо из-за занятости вводом/выводом к моменту его вызова не происходит удаления старого сокета. Позже -- происходит.

Первый sleep вроде как должен помочь в случае с e2k, вот только какой? Ни 2, ни 5, ни 180 секунд нам не помогли. Второй sleep вкорячивали перед alterator-wait -- второй как раз наш случай с 8СП на x86_64, сегодня с этой машиной последний день можем работать.

Встречный вопрос: кто выводит сообщение про сокет -- понятно:

http://git.altlinux.org/gears/a/alterator.git?p=alterator.git;a=blob;f=alterator/interfaces/guile/d.scm;h=dcbebbe7cd64d23504ad22009cef270b577b52a4;hb=2c29233a3f88ef85f3d3c93adc78eb8da61ed57a#l119

Непонятно, почему в выводе у mike@ этот d.csm числится как неизвестный файл? Не может это быть симптомом ошибочной компиляции на лету?

Что я заметил по коду:

* в backend3/preinstall перемонтируется в первой строчке просто /run, а во второй — /var/run (потому что alteratord_socket_dir == /var/run/...):

  mount -o bind /run $destdir/run
  mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir

не есть ли это ошибка?

>> А как же alterator-wait из того же самого скрипта?
> Обязан, но не ждёт.

* (d-wait) , т.е. alterator-wait может выйти из цикла только, если retcode будет равен 200 (либо по exception). Собственно код установки соединения находится в vhttpd/lib/http_client.c. Что там происходит и что может произойти странного, чтобы 200 вернулось тогда, когда не надо? Можно ли сделать этот код более надёжным?

* тестовая пересборка vhttpd иногда завершается с ошибкой в %check, причём именно в части unix-guile, т.е. в том тесте, где используется request-unix-server:

  make[1]: Entering directory '/usr/src/RPM/BUILD/vhttpd-0.7.10/test'
  Running "vhttpd"...
  Completed "vhttpd": 193 passes, 0 failures, 0 exceptions.
  Running inet-socket... ok
  Running unix-socket... ok
  Running inet-channel... ok
  Running unix-channel... ok
  Running inet-http... ok
  Running unix-http... ok
  Running unix-from-socket-http... ok
  Running unix-guile... FAILED

(В ответ на комментарий №12)

> * (d-wait) , т.е. alterator-wait может выйти из цикла только, если retcode
> будет равен 200 (либо по exception).

На случай exception предлагаю вот такой патч:

diff --git a/alterator-preinstall/backend3/preinstall b/alterator-preinstall/backend3/preinstall
index 77a2bfe..34f0d76 100755
--- a/alterator-preinstall/backend3/preinstall
+++ b/alterator-preinstall/backend3/preinstall
@@ -76,7 +76,7 @@ run_preinstall()
 	chroot $destdir /etc/init.d/alteratord start
 
 	# wait until new alteratord is ready to use
-	alterator-wait
+	while ! alterator-wait; do sleep 1; done
 
 	# notify interface about finish
 	notify "done #t"

Хорошая новость: как и в случае с p9, в новых ИК 8СП сборках нет этой ошибки на проблемном экземпляре.

(In reply to comment #12)
> * в backend3/preinstall перемонтируется в первой строчке просто /run, а во
> второй — /var/run (потому что alteratord_socket_dir == /var/run/...)

/var/run/alteratord/.socket создаётся внутри целевой системы. Но почему тогда в установочной системе rm -f /tmp/alterator/.socket -- вот что вообще за сокет?

>   mount -o bind /run $destdir/run
>   mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir
> 
> не есть ли это ошибка?

Мы вчера с shaba@ тоже пробовали добавить /var/run -- стало ещё хуже, инсталлятор сразу вылетает. Более того, данный код везде работает и проблем не вызывает, только на одной машине и только в режиме UEFI. Но теперь возникает ощущение, что ошибка при выполнении именно этих трёх строк, вот только почему?

> >> А как же alterator-wait из того же самого скрипта?
> > Обязан, но не ждёт.

Проверил специально -- как раз alterator-wait работает ожидаемым образом. Запускал и останавливал снаружи и в чруте, всё отрабатывает корректно. Но непонятно, почему в данном коде несмотря НА клиент продолжает работать со СТАРЫМ альтератором, а не с новым? Сразу после выпадения:

mount |tail -n2
runfs on /mnt/destination/run type tmpfs (...)
/dev/sda4 on /var/run/alteratord type ext4 (...) <-- тут корневой раздел

/var/run/alteratord/.socket после выпадения в наличии. Клиент продолжает разговаривать со старым демоном, до выпадения он доступен, поэтому alterator-wait сразу возвращает $?=0.

(В ответ на комментарий №14)

> Но почему тогда в установочной системе rm -f /tmp/alterator/.socket -- вот что вообще за сокет?

  В коде написано rm -f $alteratord_socket_dir/.socket т.е. rm -f /var/run/alteratord/.socket . Никакого /tmp/alterator там нет. Сам же выше писал:

> В /tmp нет сокетов демона, там сокет клиента browser-qt.

  Так что это другой сокет.

> >   mount -o bind /run $destdir/run
> >   mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir
> > 
> > не есть ли это ошибка?
> 
> Мы вчера с shaba@ тоже пробовали добавить /var/run -- стало ещё хуже,
> инсталлятор сразу вылетает.

  Давайте всё таки попробуем внести ясность. Второй mount выводит сокет демона из чрута наружу. А что делает первый mount, для чего он вообще нужен? Для всех остальных программ, просто, чтобы в чруте был /run на runfs?

  Я не доконца понимаю текущую ситуацию с /run и /var/run, поэтому рискну предположить: после прямой проекции /run в /mnt/destination/run обратная проекция из /mnt/destination/var/run наружу теряет смысл, поскольку к этому моменту /mnt/destination/run === /mnt/destination/var/run === /var/run === /run .
  Нельзя ли породить в чруте свой, отдельный /run на runfs и убрать первый mount?

> > >> А как же alterator-wait из того же самого скрипта?
> > > Обязан, но не ждёт.
> 
> Проверил специально -- как раз alterator-wait работает ожидаемым образом.

  Наверное. Только вот alterator-wait всё-таки работает на стороне бакенда. А нам же нужно чтобы ещё и клиент дождался. А вернее: чтобы клиент _переподключился_ (см. ниже).

> Но непонятно, почему в данном коде несмотря НА клиент продолжает работать
> со СТАРЫМ альтератором, а не с новым? Сразу после выпадения:

  Признаться, в части альтератора, с инсталлятором я работал меньше всего, поэтому не понимаю этой магии с подменой сокета. Расскажите мне, в каком месте кода _клиент_ отключается от старого сокета и подключается к новому? Потому что без переподключения, удаление "файла" $alteratord_socket_dir/.socket, которое делает бакенд, ведь не приведёт к нарушению ранее установленного соединения: в UNIX-системах даже удаление обычного файла не мешает программе продолжать чтение из него по открытому fd до следующего close() + open()? , так ведь?

  И вот пока вижу следующее: внутри кода backend3/preinstall, некий процесс, который кстати сказать, работает в фоновом режиме (&), вызывает программу alterator-wait, которая запрашивает новое соединение с новым сокетом (который только что был проброшен наружу mount -o bind), и получает его. Но почему это должно как-то повлиять на уже установленное соединение между alterator-wizardface и старым сокетом (файл которого был только что удалён ну и что)?

(В ответ на комментарий №8)

> Немного разобрался в машинерии. Основной клиент -- guile-скрипт
> /usr/sbin/alterator-wizard создаёт в /tmp FIFO и работает через него в паре с
> /usr/bin/alterator-browser-qt. Независимо от происходящего в инсталляторе,
> примерно раз в секунду один запрашивает у другого авторизацию анонимуса и тут
> же получает положительный ответ.

Так может быть вся магия переподключения клиента строится вот на этом "раз в секунду"?! Если так, то предполагаю такой сценарий:

1. backend3/preinstall удаляет старый сокет;
2. ставит на его место новый;
3. посредством alterator-wait ждёт и проверяет, что новый сокет готов к работе;
4. отправляет клиенту "done" в СТАРЫЙ сокет (а куда же ещё, ведь он продолжает работать под СТАРЫМ alteratord!);
5. клиент читает "done" из СТАРОГО сокета (в новый сокет "done" в принципе никто не отправлял);
6. благодаря "опросу примерно раз в секунду" переход к новому шагу инсталлятора должен привести и к подключению к новому сокету, но не приводит, потому что опрос не успевает произойти.

И где, кстати, эта машинерия с "авторизацией анонимуса"?

(In reply to comment #15)
>   В коде написано rm -f $alteratord_socket_dir/.socket т.е. rm -f
> /var/run/alteratord/.socket . Никакого /tmp/alterator там нет.

В каком коде? Вот здесь и во всех образах код одинаковый:

http://git.altlinux.org/gears/a/alterator-preinstall.git?p=alterator-preinstall.git;a=blob;f=alterator-preinstall/backend3/preinstall;h=a34822c32f753c20907e6894b29e3357d33b47d9;hb=13c881a5d2d9f6de0df304c1b0e4e688caa8df2d#l68

Удаляется что-то другое и это в 99.999% волшебным образом работает.

> Сам же выше писал:
> > В /tmp нет сокетов демона, там сокет клиента browser-qt.

Так и есть -- там только /tmp/alterator/broser-sock.

> > >   mount -o bind /run $destdir/run
> > >   mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir
> > > 
>   Давайте всё таки попробуем внести ясность. Второй mount выводит сокет демона
> из чрута наружу. А что делает первый mount, для чего он вообще нужен? Для всех
> остальных программ, просто, чтобы в чруте был /run на runfs?

Обычно в чруте достаточно смонтировать /proc, /sys и /dev. Так что зачем здесь нужен /run -- хороший вопрос, но скорее к git blame.

> Нельзя ли породить в чруте свой, отдельный /run на runfs и убрать первый
> mount?

Мне казалось, правки shaba@, о которых говорилось выше, именно это и делают. Точнее, именно такой механизм. Он более правильный. Но данный код, кажется, они вообще не затрагивают.

> Расскажите мне, в каком месте кода _клиент_ отключается от старого сокета и
> подключается к новому? Потому что без переподключения, удаление "файла"
> $alteratord_socket_dir/.socket,

Про клиента ничего не знаю -- это Ваша епархия. Очевидно стек scm'ов от telegraph до ранее упомянутого d.csm (предположительно). А бэкэнд -- в этом самом месте preinstall. Я попробовал поменять код на правильный, но это ничего не дало. В смысле rm -f $alteratord_socket_dir/.socket приводит к тому же выпадению инсталлятора. До этого ошибся буквой и результат тот же. На следующем заходе гляну, что там ещё в /tmp/alterator ДО начала. Но похоже, что этот rm вообще ни на что не влияет. Заменил его пока на остановку alteratord с подавлением вывода.

> в UNIX-системах даже удаление обычного файла не мешает программе продолжать
> чтение из него по открытому fd до следующего close() + open()? , так ведь?

Да, всё верно. Но если мы имеем дело со скриптом, нужно ухитриться открыть дескриптор, удалить элемент каталога и далее продолжить работать с открытым файлом (сокетом). Точнее сказать, это делается круглыми и угловыми скобками с амперсандами и в обсуждаемом preinstall этого не видать.

> почему это должно как-то повлиять на уже установленное соединение между
> alterator-wizardface и старым сокетом (файл которого был только что удалён
> ну и что)?

Хороший вопрос. Так никто не говорит, что ошибка именно в preinstall. Но искать-то проще там, где подсвечивает, в смысле именно с этими тремя строками в preinstall параллельно должен работать клиент. Предположу, что там сделан игнор на разрыв трубы, а в/в через неё не частый -- по крайней мере, именно такую реализацию я видел в нём же собственного внутреннего сокета browser-sock.

(В ответ на комментарий №17)
> (In reply to comment #15)
> >   В коде написано rm -f $alteratord_socket_dir/.socket т.е. rm -f
> > /var/run/alteratord/.socket . Никакого /tmp/alterator там нет.
> 
> В каком коде? Вот здесь и во всех образах код одинаковый:
> 
> http://git.altlinux.org/gears/a/alterator-preinstall.git?p=alterator-preinstall.git;a=blob;f=alterator-preinstall/backend3/preinstall;h=a34822c32f753c20907e6894b29e3357d33b47d9;hb=13c881a5d2d9f6de0df304c1b0e4e688caa8df2d#l68
> 
> Удаляется что-то другое и это в 99.999% волшебным образом работает.

  Извиняюсь. Это у меня почему-то версия alterator-preinstall до сих пор обгоняет Сизиф:

http://git.altlinux.org/people/manowar/packages/?p=alterator-preinstall.git;a=shortlog;h=refs/heads/master

  Я и подумать не мог, что его столько времени никто не менял, учитывая это наше обсуждение ошибки.

Вопчем думаю, что нужно точно разобраться с тем, как переподкючается клиент и сделать эту процедуру более надёжной.

(In reply to comment #18)
> http://git.altlinux.org/people/manowar/packages/?p=alterator-preinstall.git;a=shortlog;h=refs/heads/master

chroot $destdir /etc/init.d/alteratord start

А не нужно ли в этом месте бэкэнда подавлять вывод: >/dev/null 2>&1 ?

(In reply to comment #13)
> -    alterator-wait
> +    while ! alterator-wait; do sleep 1; done

Вот это вообще было хорошей идеей, попробовал, но ничего не дало.

(In reply to comment #0)
> _Возможно_, надо перенести монтирование новых tmpfs из alterator-pkg в
> alterator-preinstall _до_ запуска второго alteratord.

Наблюдаю интересную вещь: нет /tmp/alterator/.socket _до_ начала инсталляции. В процессе инсталляции здесь рядышком появляется browser.sock и больше ничего. Остановка alteratord в установщике в любом месте preinstall приводит к зависанию клиента наглухо на стадии "Сохранение настроек", до перехода к шагу /grub.

Это и что было раньше говорит только об одном: клиент связан с alteratord в установочной системе очень крепко, и его сокет изначально перекрыт либо через /tmp/alterator, либо через /tmp, скорее второе. Поэтому rm -f не работает. И пока клиент крепко связан с установочным alteratord, появление нового сокета в /var/run/alteratord/.socket ни на что не влияет. Это в случае рейса.

(In reply to comment #19)
> Впрочем думаю, что нужно точно разобраться с тем, как переподкючается клиент
> и сделать эту процедуру более надёжной.

Очень верное направление. Но без железа, где проявляется баг, этот рейс можно искать очень долго. Надеюсь, удастся выцепить такую машинку. Со стороны бэкэнда перепробованы все варианты, отлаживать просто нечего. Впрочем, перекрытие сокета через /tmp в случае рейса может иметь место в другом скрипте. Жаль, не осталось времени на отладку, ухожу в отпуск.

(В ответ на комментарий №21)
> (In reply to comment #19)
> > Впрочем думаю, что нужно точно разобраться с тем, как переподкючается клиент
> > и сделать эту процедуру более надёжной.
> 
> Очень верное направление. Но без железа, где проявляется баг, этот рейс можно
> искать очень долго. Надеюсь, удастся выцепить такую машинку.

Да по боку этот рейс и машинку! Я просто хочу выяснить, как сейчас происходит переподключение клиента (вернее, должно происходить), после чего сделать это надёжно, а не лечить симптомы.

(In reply to comment #22)
> (В ответ на комментарий №21)
> > (In reply to comment #19)
> > > Впрочем думаю, что нужно точно разобраться с тем, как переподкючается клиент
> > > и сделать эту процедуру более надёжной.
> > 
> > Очень верное направление. Но без железа, где проявляется баг, этот рейс можно
> > искать очень долго. Надеюсь, удастся выцепить такую машинку.
> 
> Да по боку этот рейс и машинку! Я просто хочу выяснить, как сейчас происходит
> переподключение клиента (вернее, должно происходить), после чего сделать это
> надёжно, а не лечить симптомы.
/var/run/alteratord/.socket создаётся внутри целевой системы. Но почему тогда в
установочной системе rm -f /tmp/alterator/.socket -- вот что вообще за сокет?

; /var/run/alteratord is also used in installer
; to bounce the socket between stage3 and stage2;
; it's also more secure than predefined /tmp subdir
; NB: a copy contained in ../interfaces/guile/d.scm
(define *tmpdir*
  (if (string=? *d-user* "root")
    "/var/run/alteratord"
    (string-append
      (or (getenv "TMPDIR") "/tmp")
      "/alterator")))


Другой вопрос почему в первом stage у нас приехал НЕ рут.

Может быть, будет удобно перейти на абстрактный сокет (как у X-сервера)?

https://unix.stackexchange.com/a/317531/4319 :

"An abstract socket effectively exists in all filesystem namespaces and chroots; you don't have to link anything into the chroot or namespace to use it."

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

1. первый сервер закрывает соединение и прослушивание сокета;
2. клиент на это получает "отлуп";
3. клиент (опционально) выводит сообщение (попап) "Подключение к серверу…";
4. клиент повторяет попытки подключения до тех пор, пока не устанавливает соединение;
5. второй сервер запускается;
6. второй сервер начинает прослушивать сокет;
7. клиент успешно подключается к сокету.
8. клиент убирает попап (если был) и продолжает работу в установленном порядке.

 
> Да по боку этот рейс и машинку! Я просто хочу выяснить, как сейчас происходит
> переподключение клиента (вернее, должно происходить), 

Оно должно было работать так:

59476928 (Stanislav Ievlev     2009-11-10 14:46:32 +0300 80)    # stop old alteratord and kill itself
13c881a5 (Andrey Cherepanov    2014-02-04 18:47:21 +0400 81)    #sleep 1
13c881a5 (Andrey Cherepanov    2014-02-04 18:47:21 +0400 82)    #service alteratord stop

То есть старый alteratord останавливается и клиенту приходится переподключиться.  А вот как оно работает с 2014 года -- загадка.

> > переподключение клиента (вернее, должно происходить), после чего сделать это
> > надёжно, а не лечить симптомы.
> /var/run/alteratord/.socket создаётся внутри целевой системы. Но почему тогда в
> установочной системе rm -f /tmp/alterator/.socket -- вот что вообще за сокет?

Я думаю, что когда-то сокет в установщике находился там. Потом сокет переехал, а код не поправили или поправили не полностью.

(В ответ на комментарий №27)
> > > переподключение клиента (вернее, должно происходить), после чего сделать это
> > > надёжно, а не лечить симптомы.
> > /var/run/alteratord/.socket создаётся внутри целевой системы. Но почему тогда в
> > установочной системе rm -f /tmp/alterator/.socket -- вот что вообще за сокет?
> 
> Я думаю, что когда-то сокет в установщике находился там. Потом сокет переехал,
> а код не поправили или поправили не полностью.

Нет, этот rm -f был ошибкой с самого начала, но она, видимо, ни на что не влияла с 2012 года

(В ответ на комментарий №23)
> Другой вопрос почему в первом stage у нас приехал НЕ рут.

Там везде root, см. #7.

(В ответ на комментарий №24)
> Может быть, будет удобно перейти на абстрактный сокет (как у X-сервера)?

Безопасно ли? Если первый байт 0, строка с путём начинается со второго. Т.е. вопрос выравнивая адреса и вопрос анализа строки за первым байтом для того кода, который на это не рассчитан. Пока не очень понятно, думал это сделано через отдельный домен для таких сокетов.

(В ответ на комментарий №26)
> То есть старый alteratord останавливается и клиенту приходится
> переподключиться.  А вот как оно работает с 2014 года -- загадка.

Сейчас остановка alteratord в установочной системе приводит к зависанию клиента broser-qt на операции "Сохранение настроек", клиент не видит второго запущеного в чруте альтератора. Поскольку есть пересечение по /var/run и /run, остановка в одной системе может влиять на alteratord в чруте, да хотя бы по PID'у.

(В ответ на комментарий №16)
> Так может быть вся магия переподключения клиента строится вот на этом "раз в
> секунду"?! Если так, то предполагаю такой сценарий:

Не успел ответить до отъезда, а фотки с телефона потёр (дома их оставил). В любом случае с моей строны речь шла не о серверном сокете, а о browser-sock, через который обмениваются две часть фронтэнда -- browsert-qt и quile-обёртка alterator-wizard. Так вот, там я увидел игнорирование EPIPE и сначала по strace, а потом и в коде это нашёл. Не знаю, чем обоснована такая странная реализация, тем более, речь о unix-сокете двух процессов, относящихся к фронтэнду, они до последнего никуда не деваются, переключение на новый альтератор их не должно касаться. Может, zerg@ знает?

И ещё раз: пока не знаю, как реализовано переподключение сокета на клиенте, как там вообще происходит обмен с демоном. Эту часть не смотрел хотя бы потому, что очень далёк от guile.

(В ответ на комментарий №29)
> Может, zerg@ знает?
Я этого момента не касался совсем. Если в browser и было что-то для этого, то очень давно и сделано inger@.

 
> Сейчас остановка alteratord в установочной системе приводит к зависанию клиента
> broser-qt на операции "Сохранение настроек", клиент не видит второго запущеного
> в чруте альтератора. Поскольку есть пересечение по /var/run и /run, остановка в
> одной системе может влиять на alteratord в чруте, да хотя бы по PID'у.

Хмм.. Так может быть надо не делать service aleratord stop, а до запуска второго альтератора запоминать pid первого и прицельно его прибивать?

(В ответ на комментарий №29)

> Так вот, там я увидел игнорирование EPIPE и сначала по
> strace, а потом и в коде это нашёл. Не знаю, чем обоснована такая странная
> реализация

  В том, что касается кода на Scheme, я вижу (with-ignored-sigpipe ...) в части, которая отвечает за общение между browser-qt и alterator-wizardface — http://git.altlinux.org/gears/a/alterator.git?p=alterator.git;a=blob;f=alterator/interfaces/guile/transport/pipe-channel.scm;h=25a12ee2a8686846b71162ea3e99bbda2b21f0bb;hb=2c29233a3f88ef85f3d3c93adc78eb8da61ed57a . Это не та часть, которая говорит с /var/run/alteratord/.sock.

С той же частью, которая говорит с alteratord через /var/run/alteratord/.sock, всё оказалось относительно просто: она вызывает (request-unix-server ...) **на каждую команду**, на каждый запрос — http://git.altlinux.org/gears/a/alterator.git?p=alterator.git;a=blob;f=alterator/interfaces/guile/d.scm;h=dcbebbe7cd64d23504ad22009cef270b577b52a4;hb=2c29233a3f88ef85f3d3c93adc78eb8da61ed57a#l118 . А эта функция, если посмотреть на http://git.altlinux.org/gears/v/vhttpd.git?p=vhttpd.git;a=blob;f=vhttpd/lib/http_client.c;h=4667d7b11d41d6ad46e281514981983a4d15f5c6;hb=fed6867ce8bea86f135825c60bc1288ba6159f8d#l36 , в свою очередь, **каждый раз создаёт** сокет из строки пути. Очевидно, что это и есть переподключение, а точнее, разовое подключение. Следовательно, работало всё это, скорее всего просто путём mount -o bind одного сокета поверх другого, и, таким образом, сначала запросы шли к старому сокету, а после "затенения" старого сокета новым сокетом, запросы попадали в новый сокет. Если такое затенение работает правильно, то и правда, останавливать старый alteratord не обязательно.

(В ответ на комментарий №31)
> Хмм.. Так может быть надо не делать service aleratord stop, а до запуска
> второго альтератора запоминать pid первого и прицельно его прибивать?

Прибивать сигналом KILL, чтобы не было обработки TERM/QUIT/итп, вот только что будет, если в этот момент демон будет находиться в состоянии ввода/вывода?

(В ответ на комментарий №32)
> Это не та часть, которая говорит с /var/run/alteratord/.sock.

Да, выше об этом говорил.

(В ответ на комментарий №33)
> ... **каждый раз создаёт** сокет из строки пути. Очевидно, что
> это и есть переподключение, а точнее, разовое подключение. Следовательно,
> работало всё это, скорее всего просто путём mount -o bind одного сокета
> поверх другого, и, таким образом, сначала запросы шли к старому сокету, а
> после "затенения" старого сокета новым сокетом, запросы попадали в новый
> сокет.

Дело в том, что создаётся не совсем сокет, не совсем pipe и не совсем fifo, невзирая на название. Создаётся нечто подобное именованному каналу, но управляемое через Pseudo TTY a.k.a PTY (/dev/pts/%d и /dev/ptmx). И это одна из странностей реализации, на которую может влиять момент перекрытия:

mount -o bind /dev/pts $destdir/dev/pts

Мне вообще этот старый код с mount -o bind не нравится, я бы биндил только /dev, всё остальное же монтировал заново, как shaba@ это сделал с /run и как предлагалось "планом Бидермана". Зачем *здесь* вообще PTY? Тем более, зачем он нужен при обмене одной части фронтэнда с другой да ещё с авторизацией раз в секунду?

Очень важное пояснение можно найти здесь: https://lwn.net/Articles/688809/
См. также: [alterator.git]/alterator/src/libguile-pipe/terminal.c

Я вот тут подумал, а что если сделать пока вот так:

diff --git a/alterator-net-eth/ui/net-eth/index.scm b/alterator-net-eth/ui/net-eth/index.scm
index c46df1e..72c9ee0 100644
--- a/alterator-net-eth/ui/net-eth/index.scm
+++ b/alterator-net-eth/ui/net-eth/index.scm
@@ -337,7 +337,7 @@
 
 (document:root
   (when loaded
-	(init-interface)
+	(catch/message init-interface)
     (form-bind "name" "change" update-interface)
 	(form-bind "ipv" "change" ipv_changed)
 	(form-bind "ipv_enabled" "change" update-ipv-activity)

Есть шанс, что после этого инсталлер не будет падать после установки пакетов, а будет выводить окошко с ошибкой. Попробуйте, пожалуйста. Если получится, то можно будет написать workaround получше, на уровне frame:next, например — чтобы он делал несколько попыток подключения к бакенду. А можно и ещё глубже его зарыть: сделать, например, так, чтобы в случае "backend not found", сама d-qeury повторяла бы попытки. Ну и сделать, например, так, чтобы количество попыток настраивалось (т.к. нигде, кроме инсталлера, это повторение наверняка не нужно).

Правда, делать новые попытки подключения имеет смысл только в том случае, если там сейчас действительно гонка. Если же новый сокет (второго alteratord) не доступен совсем — ни с первой, ни с двадцатьпервой попытки, то это другая проблема.

(В ответ на комментарий №35)
> Есть шанс, что после этого инсталлер не будет падать после установки пакетов, > а будет выводить окошко с ошибкой.

Судя по трассировке от mike@, самого шага /net-eth в системе НЕТ:

ice-9/boot-9.scm:109:20: Throw to key `woo-error' with args `("backend not
found: net-eth")'.

Он есть в целевой системе, здесь же вызов произошёл в установочной системе. Так что правка фронтэнда этого шага точно не поможет. Тем более, на e2k нет шага /grub, а за установкой пакетов может быть разное, в зависимости от инсталлятора.

> А можно и ещё глубже его зарыть: сделать, например, так, чтобы в случае
> "backend not found", сама d-qeury повторяла бы попытки.

ДА. Трассировка у mike@ начинается с:

[alterator.git]/interfaces/guile/transport/pipe-channel.scm

Но это поможет только в случае e2k, где попытка поговорить с бэкэндом успевает проскочить до того, как alteratord запустился в целевой системе. При перекрытии /tmp или /tmp/alterator, как в случае рейса на 8СП, это тоже не поможет.

(В ответ на комментарий №36)
> При перекрытии /tmp или /tmp/alterator, как в случае рейса на 8СП,
> это тоже не поможет.

А может и поможет. Ведь всё дело в нескольких секундах на стороне фронтэнда и перекрытие /tmp/alterator не должно влиять, как уже выяснили выше: настоящий путь к сокету вообще не здесь, а в /var/run.

В d.csm или ещё глубже trow-cacth в цикле из нескольких попыток с задержкой в пару секунд и проверкой на предмет именно ошибки связи с сокетом либо отсутствии шага (не важно какого). То же самое на стороне бэкэнда не помогло.

(В ответ на комментарий №37)

> В d.csm или ещё глубже trow-cacth в цикле из нескольких попыток с задержкой в
> пару секунд и проверкой на предмет именно ошибки связи с сокетом либо
> отсутствии шага (не важно какого).

Ты это уже попробовал сделать или это только идея? Не понял.

(В ответ на комментарий №38)
> Ты это уже попробовал сделать или это только идея? Не понял.

Как я могу опробовать вашу идею, если не владею guile? Но идею поддерживаю! :)

(В ответ на комментарий №37)
> (В ответ на комментарий №36)
> > При перекрытии /tmp или /tmp/alterator, как в случае рейса на 8СП,
> > это тоже не поможет.
> 
> А может и поможет. Ведь всё дело в нескольких секундах на стороне фронтэнда и
> перекрытие /tmp/alterator не должно влиять, как уже выяснили выше: настоящий
> путь к сокету вообще не здесь, а в /var/run.

Удаление было по неправильному пути, а вот перекрытие, насколько я могу судить 00 по правильному, в /var/run
Иначе бы вообще ничего и никогда не работало.

(В ответ на комментарий №40)
> перекрытие, насколько я могу судить
> 00 по правильному, в /var/run
> Иначе бы вообще ничего и никогда не работало.

В случае рейса на 8СП, который пока непонятно, как и на чём отловить, мы имеем биндинг /var/run/alteratord в обратную сторону и именно он почему-то при рейсе работает не так, как ожидается -- клиент продолжает разговаривать со старым альтератором, хотя перекрытие произошло несколькими командами выше. Ранее уже обсудили, что при разговоре клиент устанавливает соединение *каждый раз* новое. Что это значит в случае рейса на 8СП? Может такое быть, что на 8СП при рейсе где-то включается отдельный mount namespace и это перекрытие не срабатывает?

А ты замелил, что в бакенде стоит sync после notify?

	# notify interface about finish
	notify "done #t"
	sync

Может он иметь какое-то отношение к mount -o bind и к этим сокетам, которые "не совсем сокеты, не совсем pipe и не совсем fifo, невзирая на название"? Или это такой sync, чтобы notify быстрее долетел? Что-то не нравится он мне. Особенно в связи с гонкой.

(В ответ на комментарий №42)
> Может он иметь какое-то отношение к mount -o bind и к этим сокетам...?

К связи с альтератором он никакого отношения не имеет. Это следует из комментария над данным сниппетом, из смысла функции notify() в том же скрипте и из [alterator-lookout.git]/alterator-lookout/tools/alterator-mailbox-send.c -- бэкэнд сообщает фронтэнду ("done #t") о завершении операции "Saving settings...", которая и есть шаг /preinstall, и в процессе которой запускаются всякие скриптики.

sync здесь можно рассматривать двояко: как sleep(ramdom()) и как приостановку какого-либо ввода/вывода до сброса всех буферов на диск. С точки зрения возможности рейса -- фактор провоцирующий, ага. Но влепили его сюда наверняка вместо sleep(n), чтобы дать кому-то (чему-то) другому что-то успеть доделать.

Например, в том же d.csm есть такой комментарий:

note: don't use control script, because init script pass all stderr to initlog

Управляющий скрипт здесь, надо понимать, это guile-обёртка над функциями запуска/остановки alteratord. Только в d.csm это цикл ожидания с конкретной задержкой до выполнения условия. Можно предположить, что sync'ом в бэкэнде /preinstall могли преследовать те же цели, но не очень надёжным способом. Если так, то для нашего бага сейчас не критично.

Мне куда больше не нравится этот d.csm и вообще весь guile. :-)

(В ответ на комментарий №42)
>     # notify interface about finish
>     notify "done #t"
> [...]
> Может он иметь какое-то отношение к mount -o bind и к этим сокетам...?

Забыл сказать: notify() имеет отношение к т.н. "клиентскому" сокету a.k.a /tmp/alterator/browser-sock. А вот какое отношение этот сокет имеет ко всей архитектуре альтератора, честно говоря, понять пока так и не смог (нет нужных знаний guile). Сейчас он вообще вынесен за пределы альтератора!

Почему бинд-маунтится /tmp/alterator, где кроме этого сокета лежит ещё и журнал альтератора? В то же время, журнал фронтэнда лежит в /tmp/wizard.log и сабжевый баг (у mike@), судя по успешному откату коммита shaba@, может быть связан именно с этим журналом или способом монтирования в чрут каталога /tmp. Почему один сокет (клиентский) всегда был в /tmp/alterator, а серверный несколько раз прыгал и переименовывался? И как так получилось, что теперь они разнесены?

В поисках ответов на эти вопросы набрёл на то, в чём могут разобраться только аксакалы guile...

1) Когда-то "клиентский" сокет был частью альтератора, а именно одним из транспортов наряду с серверным сокетом. Сейчас есть только один транспорт -- pipe-channel.csm и его код весьма напоминает бывший "серверный" транспорт. См.:

git show 68d028

2) Вот несколько изменений в историческом порядке [alterator.git], которые не были косметическими переименованиями, но касались этих двух сокетов:

git show 530a3a
git show ab2072..df792a
git show 00a51c..c65360

3) Нашёл в пыльном мешке вот это, но ничего не понял:
https://www.altlinux.org/Alterator/drivers/http

4) А вот это мастрид, я считаю:
https://www.altlinux.org/Socket_race_conditions
И не просто мастрид, а брать напильник и дотачивать d.csm!

5) Возможно, на ситуацию с 8СП как-то влияет этот коммит (c) твой:

git show 71f4ff

6) См.: [alterator-wizardface.git]/alterator-wizardface/sbin/alterator-wizard и [alterator-browser-qt5.git]/alterator-browser-qt/browser.cc#184-204 для понимания ситуации с "клиентским" сокетом -- тут код, который не трогал zerg@.

7) Мне больше не нравится обратное монтирование: возможно, сторонний эффект на конкретном железе из-за ошибок в ядре?

8) Если бы знал guile, я бы воспроизвёл ситуацию на e2k, вернув коммит shaba@, поизучал бы кэш "компиляции на лету" и ситуацию с трассировкой, в которой единственный модуль d.csm превращается в *неизвестный файл*.

Попробую в деталях разжевать ситуацию mike@ на e2k. Код, который трогал shaba@ -- [alterator-pkg]/alterator-pkg/backend3/pkg-init:

# 19: /run теперь в скелете будущего чрута
mkdir -p /mnt/destination/run

# 42: создание других служебных каталогов
mkdir -p /mnt/destination/dev
mkdir -p /mnt/destination/dev/pts
mkdir -p /mnt/destination/proc
mkdir -p /mnt/destination/sys
mkdir -p /mnt/destination/tmp/alterator

# 43: эти же каталоги будут и в чруте
mount --bind /dev /mnt/destination/dev
mount --bind /dev/pts /mnt/destination/dev/pts
mount --bind /proc /mnt/destination/proc
mount --bind /sys /mnt/destination/sys
mount --bind /tmp/alterator /mnt/destination/tmp/alterator

На самом деле из #42-43 убран только /run, остальное так было и раньше. Что здесь плохо (сугубо на мой взгляд), с учётом вышеупомянутого "плана Бидермана" и использования PTY для управления одним из сокетов, что /dev/pts биндится в чрут, тогда как безопаснее сделать новый экземпляр, и тогда у каждой системы будут независимые PTY's, т.е.:

-mount --bind /dev/pts /mnt/destination/dev/pts
+mount -t devpts devpts /mnt/destination/dev/pts

# 46: add symlinks /var/run -> /run, and /var/lock -> /run/lock
# 47: теперь /run в чруте -- это независимый экземпляр.
#     Кстати, зачем здесь mount с "-n"?
mount -n -t tmpfs -o mode=755 runfs /mnt/destination/run

# 48: пока единственное, что будет в чрутовом /run -- пустой под-каталог lock
mkdir -p -- /mnt/destination/run/lock

# 49: в чруте /var/run будет указывать теперь на /run
ln -s ../run /mnt/destination/var/run

# 50: в чруте /var/lock будет указывать теперь на /run/lock
ln -s ../run/lock /mnt/destination/var/lock

Сокеты запущенного альтератора установочной системы после выполнения этих строк будут находиться в:

1) /var/run/alteratord/.socket -- серверный
2) /tmp/alterator/browser-sock -- клиентский
3) /mnt/destination/tmp/alterator/browser-sock -- клиентский

Журналы будут писаться в /var/run/alteratord/alteratord.log и /tmp/wizard.log, соответственно. Пока всё выглядит прилично. И это подтверждается тем фактом, что даже в случае гонок шаг /preinstall ("Сохранение настроек") выполняется до конца, затык происходит дальше -- при попытке переключиться на чрутовый alteratord.

Теперь смотрим код, который shaba@ не трогал -- [alterator-preinstall.git]/alterator-preinstall/backend3/preinstall:

# 38: разве вывод на stdout/stderr этой функции или отдельных вызовов в ней не должен подавляться?
run_preinstall()

# 67: главное -- вовремя проверить! А ничего, что этот шаг уже на 99.9% выполнен не в той системе!? :)
[ -n "${ALTERATOR_DESTDIR:-}" ] || return

# 68: ошибка с самого начала, которая ни на что не влияет, но сбивает с толку
rm -f /tmp/alterator/.socket

# 69-71: собственно сабж
mount -o bind /run /mnt/destination/run
mount -o bind /mnt/destination/var/run/alteratord /var/run/alteratord
chroot /mnt/destination /etc/init.d/alteratord start

Этот код всегда был безобразен и до изменений shaba@ в другом пакете. 69 строка пустила насмарку всё, что ранее делалось в pkg-init#47-50, она здесь вообще лишняя: /run уже был смонтирован в чрут более правильным способом. В 70 строке выполняется *обратное монтирование* пока ещё *пустого* каталога /var/run/alteratord -- ой, здесь же только что был наш серверный сокет, куда он делся!? А куда девался журнал альтератора!?

После выполнения именно 70 строки мы гарантированно получили ситуацию гонок: если будет иметь место обращение к серверному сокету с какой-либо стороны *в установочной системе*, то сокета здесь УЖЕ нет, а появится он тут лишь после выполнения строки 71, но это займёт время... где-то в коде попадалось -t 60, возможно(!) означающее тайм-аут ожидания соединения. Но в случае рейса, а на некоторых системах здесь может иметь место интенсивынй ввод/вывод, запуск альтератора в чруте мог затянуться на более, чем 60 (секунд, надо полагать). Это единственное, чем можно объяснить вот это:

?: 2 [request-unix-server "/var/run/alteratord/.socket" ...]

(В ответ на комментарий №15)
>   Я не доконца понимаю текущую ситуацию с /run и /var/run, поэтому рискну
> предположить: после прямой проекции /run в /mnt/destination/run обратная
> проекция из /mnt/destination/var/run наружу теряет смысл, поскольку к этому
> моменту /mnt/destination/run === /mnt/destination/var/run === /var/run === /run

На мой взгляд сабжевый код должен был выглядеть как-то так:

chroot /mnt/destination /etc/init.d/alteratord start
chroot /mnt/destination alteratord-wait
mount --bind /mnt/destination/var/run/alteratord /var/run/alteratord

При этом сохраняется по сути CVE с правами и владельцами сокета и выше лежащего каталога, описанная в #11, не влияющая на ход установки только благодаря тому, что вся инсталляция выполняется из-под рута. И при этом остаётся *обратное монтрирование*, отражаемое в /proc/mounts довольно странно:

mount |tail -n2
runfs on /mnt/destination/run type tmpfs (...)
/dev/sda4 on /var/run/alteratord type ext4 (...) <-- тут корневой раздел

(В ответ на комментарий №44)
 
> Забыл сказать: notify() имеет отношение к т.н. "клиентскому" сокету a.k.a
> /tmp/alterator/browser-sock. А вот какое отношение этот сокет имеет ко всей
> архитектуре альтератора, честно говоря, понять пока так и не смог (нет нужных
> знаний guile). Сейчас он вообще вынесен за пределы альтератора!

Архитектура. Конечно, не классический MVC, но около того. Этот сокет нужен для связи между View и Model, а не для связи между Model и Controller.

> Почему бинд-маунтится /tmp/alterator,

Где это происходит?

    mount -o bind /run $destdir/run
    mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir

Тут нет ни /tmp, ни $TMPDIR.

> 1) Когда-то "клиентский" сокет был частью альтератора, а именно одним из
> транспортов наряду с серверным сокетом. Сейчас есть только один транспорт --
> pipe-channel.csm

Почему? В d.scm идёт вызов к request-unix-server, который, через обёртку, превращается ведь в request_unix_server() из http_client.c пакета vhttpd. Отсюда два следствия: 1) этот транспорт — не pipe-channel; 2) та часть d.scm, с которой мы сейчас столкнулись, написана на C, а не на Scheme.

(В ответ на комментарий №44)

> 4) А вот это мастрид, я считаю:
> https://www.altlinux.org/Socket_race_conditions
> И не просто мастрид, а брать напильник и дотачивать d.csm!

А вот, кстати сказать, абстрактные сокеты, которые предлагались выше. Что у них с правами доступа? Можно ли как-то их регулировать?

(В ответ на комментарий №46)
> > Почему бинд-маунтится /tmp/alterator,
> Где это происходит?
> Тут нет ни /tmp, ни $TMPDIR.

Тут: [alterator-pkg]/alterator-pkg/backend3/pkg-init#43

Извиняюсь за много букв. Ряд вопросов отпал при изучении. Убил вчера весь день на эту головоломку. Как и серверный сокет, журнал сервера может находиться в двух местах, в зависимости от пользователя, но в нашем случае он ложится в /var/run/alteratord.

Главное, что один рейс в бэкэнде точно найден (комментарий #45), осталось только его убрать :)

(В ответ на комментарий №47)
> А вот, кстати сказать, абстрактные сокеты, которые предлагались выше.
> Что у них с правами доступа? Можно ли как-то их регулировать?

В сишном коде или на шеле я бы поучаствовал, но с guile ничем не могу помочь. :) Предлагается исправлять по образцу, как в этой статье на ВиКи.

(В ответ на комментарий №47)
> А вот, кстати сказать, абстрактные сокеты, которые предлагались выше.
> Что у них с правами доступа? Можно ли как-то их регулировать?

Чего-то я тупанул. Здесь же речь о предложении imz@. man 7 unix, однако.))

Пространство имён абстрактного сокета является непереносимым расширением Linux. Абстрактные сокеты автоматически исчезают, когда закрыты все открытые ссылки на сокет. Нам это подходит?

Права доступа и владельцы не имеют смысла для абстрактных сокетов: umask не действует при связывании абстрактного сокета, а изменение владельца и смена прав доступа через fchown/fchmod не влияет на доступность сокета. Он вообще живёт в своём пространстве имён, не связанном с файловой системой.

Абстрактный адрес сокета отличается от классического сокета UNIX, основанного на пути в файловой системе, тем, что sun_path[0]=0. Адрес сокета в этом пространстве имен задается дополнительными *байтами* в sun_path, которые покрываются указанной длиной структуры адреса. Нулевые байты в имени не имеют особого значения.

Пока есть вот такой патчик для реконнекта в случае недоступности alteratord:

http://git.altlinux.org/people/manowar/packages/?p=alterator.git;a=commitdiff;h=fce6b361be91d7092e4fc0a444d75f1a8a77b77b

и, соответственно,

http://git.altlinux.org/people/manowar/packages/?p=alterator-wizardface.git;a=commitdiff;h=0c1750951158f6bdc5b4a1d071876b2c12e121d0

У него, правда, есть проблемы со стеком (из-за колбэка), которые я сейчас постараюсь решить. И следом займусь реконнектом для ситуации, когда соединение с alteratord есть, но "бакенд не найден". Там несколько посложнее.

Вот новая редакция коммита: http://git.altlinux.org/people/manowar/packages/?p=alterator.git;a=commitdiff;h=ade0288979795f4ed3f794f2dc4d764c8a94408d . Проблем со стеком теперь быть не должно.

Значит так, товарищи. Проверенные коммиты получились вот такими:

1. переподключение, если alteratord недоступен —
1.1. http://git.altlinux.org/people/manowar/packages/?p=alterator.git;a=commitdiff;h=69d2c04a3ebfdfa860371011149c3cb49d082c42 и
1.2. http://git.altlinux.org/people/manowar/packages/?p=alterator-wizardface.git;a=commitdiff;h=0c1750951158f6bdc5b4a1d071876b2c12e121d0 ;

2. повтор запроса, если бакенд не был найден —
2.1 http://git.altlinux.org/people/manowar/packages/?p=alterator.git;a=commitdiff;h=9eec34a98c4e6dcadba15346cdc5dc24cfb083b3 и
2.2. http://git.altlinux.org/people/manowar/packages/?p=alterator-wizardface.git;a=commitdiff;h=5b22b137487577058f08b41fc1d96de15d89bad5 .

Количество повторов и таймаут во втором случае — это те же самые значения, что и в первом случае (это один и тот же счётчик). В коммите выставлен в 20 раз с перерывом в 500 мс.

Теперь у нас вроде как есть защита от рейса, повышающая живучесть всей системы. Прошу проверить, помогает ли. Если сразу не поможет, то можно, наверное, выставить количество повторов в какое-нибудь неприличное значение и попробовать за это время что-то руками нахимичить — сокеты перемаунтить и т.д. Ну и сделать выводы.

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

Собственно, пока просится вот такой сценарий в alterator-preinstall:

1. остановка "внешнего" alteratord — теперь это можно делать, т.к. есть переподключение;
2. запуск "внутреннего" alteratord;
3. перемонтирование директории с сокетом наружу;
4. notify "done".

Если есть замечания или дополнения, то прошу дополнить: https://lists.altlinux.org/pipermail/devel/2019-August/208315.html .

(В ответ на комментарий №53)
> Теперь у нас вроде как есть защита от рейса, повышающая живучесть всей
> системы. Прошу проверить, помогает ли.

Мне пока не на чем (в отпуске).

> А я тем временем подумаю, какие сокеты всё-таки нам нужны, и как надёжнее
> организовать само переподключение между экземплярами alteratord в инсталлере.

Поскольку абстрактные не связаны с файловой системой, можно сделать клиентский и серверный, назвать соответственно "\0alteratord-browser" и "\0alteratord-server".

(В ответ на комментарий №54)
> Собственно, пока просится вот такой сценарий в alterator-preinstall:

 1. остановка "внешнего" alteratord — теперь это можно делать, т.к. есть
 переподключение;
+2. прямое бинд-монтирование каталога /var/run/alteratord в чрут;
 3. запуск "внутреннего" alteratord;
-3. перемонтирование директории с сокетом наружу;
 4. notify "done".

(В ответ на комментарий №56)

> +2. прямое бинд-монтирование каталога /var/run/alteratord в чрут;
>  3. запуск "внутреннего" alteratord;
> -3. перемонтирование директории с сокетом наружу;

А поечему именно так? Т.е. почему ты настаиваешь на том, чтобы второй демон завёл свой сокет в готовой директории или даже подобрал уже существующий сокет? Вместо того, чтобы он создал свой сокет с нуля и этот новый сокет стал доступен снаружи после bind? Хочу обратить внимание, что сейчас (и исторически) именно второй вариант.

(В ответ на комментарий №57)
> А почему именно так? Т.е. почему ты настаиваешь на том, чтобы второй демон
> завёл свой сокет в готовой директории или даже подобрал уже существующий
> сокет?

Прошу обратить внимание: все остальные каталоги смонтированы в чрут именно таким способом, прямым биндингом. И ничего. По идее, при остановке демона, старый сокет должен удаляться. Абстрактный наоборот, не должен, пока к нему есть другие подключения. Но с абстрактным не надо париться на предмет монтирования вообще.

> Вместо того, чтобы он создал свой сокет с нуля и этот новый сокет стал
> доступен снаружи после bind?

Новый демон должен создать свой сокет в том же месте. Старый клиент к нему подключится за счёт биндинга каталога. Прошу обратить внимание: сокета у нас два. И один (в /tmp/alterator) попадает в чрут прямым монтированием в одном скрипте, второй же попадает обратно в другом скрипте через монтирование в противоположную сторону. В разное время! Это никуда не годится. Нужно это всё делать однообразно в одном месте и в один момент.

> Хочу обратить внимание, что сейчас (и исторически) именно
> второй вариант.

Кто, если не мы, делаем историю! :) Исторически решение с обратным монтированием было плохим. Хотя нигде нет такого разграничения на прямое и обратное монтирование, такой общепринятой практики нет. Долгие поиски привели меня к тому, что, например, для докера люди спрашивали: по какой причине не поддерживается обратное монтирование? На мой взгляд, как минимум, эта практика противоречит некоторым соображениям безопасности.

Архитектурно нужно не костыли с задержками, а штатный механизм реакции на "done #t" или что-то подобное, то бишь адекватная реакция альтератора на событие перехода в чрут.

По вопросам в devel@ и абстрактным сокетам можно посмотреть раздел "Transmit file descriptors, credentials" здесь: https://kohlschutter.github.io/junixsocket/unixsockets.html и примеры авторизации с SCM_CREDENTIALS в этом мануале с примерами: https://onz.es/Que%20-%20Linux%20Socket%20Programming%20By%20Example%20-%20fly.pdf

(В ответ на комментарий №58)

> Прошу обратить внимание: сокета у нас два. И один (в /tmp/alterator) попадает
> в чрут прямым монтированием в одном скрипте

Напомни, пожалуйста, в каком. Я так до сих пор и не видел этот кусок.

В backend3/preinstall /tmp/alterator/.socket **удаляется**, но не монтируется. И это, кстати, ошибка, я считаю. После такого удаления notify() не должен работать! Если и нужно удялять какой-нибудь сокет, то только серверный.

(В ответ на комментарий №59)
> Напомни, пожалуйста, в каком. Я так до сих пор и не видел этот кусок.

Тут: [alterator-pkg]/alterator-pkg/backend3/pkg-init#43

> В backend3/preinstall /tmp/alterator/.socket **удаляется**, но не монтируется.
> И это, кстати, ошибка, я считаю.

Да, о том, что это было ошибкой с самого начала, выше уже написал Антон Бояршинов.

> После такого удаления notify() не должен работать!

Нет, удаляемый файл ни на что не влияет, он к этим сокетам не относится. А notify(), как я понимаю, связан с клиентским сокетом, с ним у нас нет проблем.

(В ответ на комментарий №53)
> Теперь у нас вроде как есть защита от рейса, повышающая живучесть всей системы.
> Прошу проверить, помогает ли. Если сразу не поможет, то можно, наверное,
> выставить количество повторов в какое-нибудь неприличное значение и попробовать
> за это время что-то руками нахимичить — сокеты перемаунтить и т.д. Ну и сделать
> выводы.

На всякий случай задание с этими изменениями + чистка alterator-preinstall:
http://git.altlinux.org/tasks/236531/

Ping? Мы Лёню ждём, да?

(В ответ на комментарий №62)
> Ping? Мы Лёню ждём, да?

Меня? Так ведь задача от тебя в редмайне. Даже когда выйду 2.09 из отпуска, проверку новой версии на e2k придётся согласовывать, вряд ли мне этим дадут заниматься. Поскольку аналогичная ситуация с вероятностью 50/50 поджидает на новых машинах AMD Ryzen и Intel x86_64 с 8СП, можно будет подключиться с оказией, но в первую очередь я бы исправил в бэкэнде явный рейс в [alterator-preinstall.git]/alterator-preinstall/backend3/preinstall#69-71 (см. комментарий #45).

Я там уже кое что поправил, и учитывая изменения в других пакетах думаю, что рейса теперь можно не бояться. Так что да, вопрос с проверкой этих изменений. Если главный полегон на E2K, то, значит, ждём mike@? Ну ещё вариант — у нас в офисе проверить, там есть какой-то E2K. Но нужны тогда вводная и образ.

Created attachment 8268 [details]
фрагмент /tmp/install2.log при e2k#23240 _с_ alterator-pkg 2.7.2

Проверил p9_e2k с таким довеском:

2019-Aug-30 16:02:49 :: test-only swift task #23240 for p9_e2k resumed by mike:
#100 build alterator-5.5-alt1.src.rpm
#200 build alterator-wizardface-2.2-alt1.src.rpm
#300 build alterator-preinstall-0.7.3-alt1.src.rpm
#400 build alterator-pkg-2.7.2-alt1.src.rpm

=> regular-jeos.iso упал в том же месте, но с несколько иным грохотом:

Error: (backend not found: root). Retry #1
[...]
ice-9/boot-9.scm:109:20: In procedure #<procedure b7e800 at ice-9/boot-9.scm:100:6 (thrown-k . args)>:
ice-9/boot-9.scm:109:20: Throw to key `woo-error' with args `("backend not found: root")'.

При этом alterator-root в образе, разумеется, есть.

(В ответ на комментарий №65)
> #100 build alterator-5.5-alt1.src.rpm
> #200 build alterator-wizardface-2.2-alt1.src.rpm
> #300 build alterator-preinstall-0.7.3-alt1.src.rpm

Предыдущее оставил, убрал #400 -- падать перестало:

> #400 build alterator-pkg-2.7.2-alt1.src.rpm

(В ответ на комментарий №65)

> => regular-jeos.iso упал в том же месте, но с несколько иным грохотом:
> 
> Error: (backend not found: root). Retry #1
> [...]
> ice-9/boot-9.scm:109:20: Throw to key `woo-error' with args `("backend not
> found: root")'.

  Слушай, он именно на ПЕРВОМ retry падает? Специально же там всё сделано, чтобы вместо падения была повторная попытка. Не понимаю пока, как такое могло случиться.
  Если падает после N попыток (там 20 вроде в alterator-wizardface из задания), то это куда не шло. Тогда можно разбираться дальше.

(В ответ на комментарий №66)

> Предыдущее оставил, убрал #400 -- падать перестало:
> 
> > #400 build alterator-pkg-2.7.2-alt1.src.rpm

  А какая версия сейчас у тебя? Что там за изменения?

(В ответ на комментарий №67)
> > Error: (backend not found: root). Retry #1
> > [...]
> Слушай, он именно на ПЕРВОМ retry падает? Специально же там всё сделано,
> чтобы вместо падения была повторная попытка. Не понимаю пока, как такое
> могло случиться.
Не, retry там 19 штук было.  Извини, слишком кратко приложенное процитировал.

(В ответ на комментарий №68)
> > Предыдущее оставил, убрал #400 -- падать перестало:
> > > #400 build alterator-pkg-2.7.2-alt1.src.rpm
> А какая версия сейчас у тебя? Что там за изменения?
Предыдущая 2.7-alt1 (см. comment 0).

(В ответ на комментарий №69)
> (В ответ на комментарий №67)
> > > Error: (backend not found: root). Retry #1
> > > [...]
> > Слушай, он именно на ПЕРВОМ retry падает? Специально же там всё сделано,
> > чтобы вместо падения была повторная попытка. Не понимаю пока, как такое
> > могло случиться.
> Не, retry там 19 штук было.  Извини, слишком кратко приложенное процитировал.

  Понял. Это другое дело. Тогда можно увеличить до 10000, к примеру, и попробовать за это время разобраться с сокетом — посмотреть в mount -l и /proc и т.д.

> 
> (В ответ на комментарий №68)
> > > Предыдущее оставил, убрал #400 -- падать перестало:
> > > > #400 build alterator-pkg-2.7.2-alt1.src.rpm
> > А какая версия сейчас у тебя? Что там за изменения?
> Предыдущая 2.7-alt1 (см. comment 0).

  Понял. Это я посмотрю завтра, что там такое могло быть, что наводит индукцию на preinstall.

Created attachment 8275 [details]
/var/run/alteratord/alteratord.log до обратного монтирования

Обратите внимание на pkg-size и концовку (отсутствующие обработчики). Это в любом случае множественные ошибки. И это последнее, что попадает в журнал перед переключением в чрут.

В том же файле, который в чруте, только две строки:

*** Make a new server socket ***
bind_unix: address /var/run/alteratord/.socket in use

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

Вместе с тем, alterator-cmdline связывается с сокетом из перекрытого чрутового каталога и чудесно обнаруживает шаг /grub.

Локализовать рейс пока не получается. Картина вообще не поддаётся объяснению.

(В ответ на комментарий №72)
 
> Вместе с тем, alterator-cmdline связывается с сокетом из перекрытого чрутового
> каталога и чудесно обнаруживает шаг /grub.
> 
> Локализовать рейс пока не получается. Картина вообще не поддаётся объяснению.

  Версия с retry будет повторять попытки до тех пор, пока /grub не будет найдет (или не истечёт количество попыток). Поэтому если cmdline связывается, то и wizardface тоже должен с очередной попытки связаться.

  И ещё, как твой репорт связан вот с этим у mike@:

>> Предыдущее оставил, убрал #400 -- падать перестало

(In reply to comment #73)
> Версия с retry будет повторять попытки до тех пор, пока /grub не найдет
> (или не истечёт количество попыток).

Применить твои изменения на старую версию 8СП проблематично -- их много и они ёмкие, я же не пересобираю старый образ, а на новых 8СП и на WS9 не воспроизводится. При этом нам оставили проблемный Intel x86_64. Кроме того, бесполезно ждать и повторять: в отличие от случая mike@, у меня коннект не рвётся, с первой же попытки проскочит. Инсталлятор при повторном запуске сразу работает с новым alteratord в чруте, поэтому не находит /steps-list. Но и старый не просто так отваливается, потому и привёл лог -- он спотыкается как раз на сокете (не почистили за собой после разрыва pipe в результате внезапного killall).

> 
>   И ещё, как твой репорт связан вот с этим у mike@:
> 
> >> Предыдущее оставил, убрал #400 -- падать перестало

Никак. Второй день дебажу 8СП на проблемном Intel x86_64, где морда продолжает работать со старым альтератором, что бы я не делал. Убрать #400 это всё равно, что не применить твои патчи, а откатить изменения shaba@, чего делать нельзя. То бишь твои изменения фронтэнда не помогли на e2k. Равно как и никакие мои изменения в бэкэндах не помогают решить и даже локализовать проблему. Но, по крайней мере, нашлось несколько конкретных ошибок, частично они выше уже описаны.

Created attachment 8279 [details]
/usr/lib/alterator/backend3/preinstall использованный для отладки

Чтобы отловить момент рейса, сделал следующее: заменил концовку в preinstall, в том числе, убрав обратное монтирование, что позволило подвесить установочный процесс на alterator-wait, вплоть до выполнения в другой консоли обратного монтирования. После этого подрубился strace'ом ко всем PID'ам альтератора одной командой и записал происходящее падение (буквально доли секунды)...

Created attachment 8280 [details]
strace момента падения: процесс alteratord

Created attachment 8281 [details]
strace момента падения: процесс alterator-qt-browser

Created attachment 8282 [details]
strace момента падения: процесс alterator-wizard

Created attachment 8283 [details]
strace происходящего в preinstall на новом образе 8СП в норме

Created attachment 8284 [details]
strace происходящего в preinstall на старом образе 8СП (падение)

Created attachment 8285 [details]
Все логи по результату падения на старом образе 8СП

Требуется детальный анализ. По-моему, разница очевидна. В прошлый раз захватывал только момент падения, внося изменения в исходники. В этот раз исходники не менял, захват в другой консоли выполнялся примерно так:

strace -o /run/$filename -f -p $pid &

для каждого интересующего процесса, всё одной строкой (командой) во втором терминале незадолго до момента предполагаемого падения, в процессе preinstall (точка начала в его середине условно примерная) и до момента падения (перехода к шагу /grub -- тоже примерно).

Теперь можно сравнить ситуацию в норме и ситуацию с падением на одной машине.

Павел, отдельным письмом передаю тебе все собранные данные с комментариями.
В МСК нашлась ещё одна машинка, где баг проявился, можем тебе её переслать.

Теперь главное -- характер системных вызовов везде одинаковый, ничего подозрительного не нашлось в 4-х сравниваемых случаях. Единственное отличие заключается в том, что в случае успеха, сразу после 4-х сбойных обращений из alterator-wizard:

stat("/usr/share/alterator/ui//grub/index.scm", 0x7ffe90f1d3e0) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/ui//grub.scm", 0x7ffe90f1d460) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub/index.scm", 0x7ffe90f1d460) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub.scm", 0x7ffe90f1d4e0) = -1 ENOENT (No such file or directory)

он продолжает перебор путей и находит нужное:

stat("/mnt/destination/usr/share/alterator/ui//grub/index.scm", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
access("/mnt/destination/usr/share/alterator/ui//grub/index.scm", R_OK) = 0
open("/mnt/destination/usr/share/alterator/ui//grub/index.scm", O_RDONLY) = 15

а в случае ошибки, сразу вылетает:

write(1, "<* ((#t))\nRET: ()\n", 18) = 18
write(2, "frame:on-next is deprecated, use"..., 966) = 966
exit_group(1)                     = ?

(В ответ на комментарий №75)

> командой и записал происходящее падение (буквально доли секунды)...

  Вот это меня несколько беспокоит: ты упорно ковыряешь одну точку, смотришь в микроскоп там, где надо бы сначала осмотреться по сторонам.

  Поэтому ещё раз прошу перейти вот к этой тактике:

>> Не, retry там 19 штук было.  Извини, слишком кратко приложенное процитировал.
>
>   Понял. Это другое дело. Тогда можно увеличить до 10000, к примеру, и
> попробовать за это время разобраться с сокетом — посмотреть в mount -l
> и /proc и т.д.

  Потому что очень не верится, что если мы имеем процесс, который постоянно повторяет попытки открыть файл F, то, имея в запасе время и консоль, нельзя в конце концов создать ему такие условия, когда он этот файл наконец откроет. В нашем случае — откроет ту версию файла, которая нам нужна. А стоит успешно закончить такой эксперимент, как всё остальное наверняка прояснится в гораздо большей степени, чем сейчас.

(В ответ на комментарий №70)

> > (В ответ на комментарий №68)
> > > > Предыдущее оставил, убрал #400 -- падать перестало:
> > > > > #400 build alterator-pkg-2.7.2-alt1.src.rpm
> > > А какая версия сейчас у тебя? Что там за изменения?
> > Предыдущая 2.7-alt1 (см. comment 0).
> 
>   Понял. Это я посмотрю завтра, что там такое могло быть, что наводит индукцию
> на preinstall.

  Вроде ж всё очевидно. #400 делает вот такую нехорошую вещь:

    ln -s ../run "$destdir/var/run"
    ln -s ../run/lock "$destdir/var/lock"

после которой разница между /run и /var/run внутри $destdir исчезает. В то же самое время, alterator-preinstall полагается в своей работе именно на то, что /run и /var/run — независимые пути:

    mount -o bind /run $destdir/run
    # Всё! Симлинк $destdir/var/run ведёт теперь в _наш_, т.е. наружный /run.

    mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir
    # Превратилось в тавтологию или чего похуже: монтируем _симлинк_
    # "$destdir/var/run -> $destdir/run" в /var/run , который, видимо,
    # просто /run, смонтированный в обе системы (логично предположить
    # что у нас во внешней системе вредный симлинк "/var/run -> /run"
    # также присутствует).

    chroot $destdir service alteratord start
    # Должен теперь бороться с нашим (внешнем) alteratord за один и тот
    # же файл сокета.


  Неудивительно, поэтому, что

> > > > Предыдущее оставил, убрал #400 -- падать перестало:

  Какие тут "протоколы альтератора", какие эс-трейсы с километрами логов?! Должно лечиться простым удалением строки

    mount -o bind /run $destdir/run

  из alterator-preinstall.  Поскольку после #400, т.е. после alterator-pkg-2.7.2-alt1, в $destdir и так есть свой собственный tmpfs и на диске, очевидно, ничего лишнего после установки не останется.

http://git.altlinux.org/tasks/236531/ -- alterator-preinstall.git v0.7.4-alt1

(In reply to comment #84)
>   Потому что очень не верится, что если мы имеем процесс, который постоянно
> повторяет попытки открыть файл F, то, имея в запасе время и консоль, нельзя в
> конце концов создать ему такие условия, когда он этот файл наконец откроет.

Это история про Эльбрус. В переводе на мою ситуацию всё наоборот -- он должен, в конце концов, прекратить работать с прежним сокетом. Но мы на самом деле не знаем, почему так происходит. И как показала практика, вкорячивание задержек мне не помогла.

> В нашем случае — откроет ту версию файла, которая нам нужна. А стоит успешно
> закончить такой эксперимент, как всё остальное наверняка прояснится в гораздо
> большей степени, чем сейчас.

По крайней мере, теперь у нас есть свободный экземпляр, где эта редкая проблема воспроизводится. И речь теперь не о локализации бага (это бы тоже не помешало, но мы и так убили на него слишком много времени), а речь об усовершенствовании механизма перехода в чрут, в целом.

Когда мы работаем с сокетом, обе стороны должны от него отключиться и удалить его. Также необходимо учитывать прерываемый ввод-вывод в сокете (не законченный ввод или вывод, прерванный в/в и возобновление после прерывания в системном вызове. Надеяться лишь на то, что каталог с сокетом будет перекрыт (в какой момент!?) и работа возобновиться через новый сокет -- в корне опрометчиво, это и есть архитектурный баг.

(In reply to comment #85)
> Должно лечиться простым удалением строки
>     mount -o bind /run $destdir/run
> из alterator-preinstall.

Думаешь, мы так не делали? Это первое, что предложил shaba@ -- не помогло. Данный инсталлятор вообще колом после этого встаёт. Позже немного разобрался, почему это происходит. Загляни ещё в pkg-init и remount.

(В ответ на комментарий №88)
> (In reply to comment #85)
> > Должно лечиться простым удалением строки
> >     mount -o bind /run $destdir/run
> > из alterator-preinstall.
> Думаешь, мы так не делали? Это первое, что предложил shaba@ -- не помогло.
Если правильно понимаю, с новым systemd это монтирование надо убирать и менять зависимое от этого.

(В ответ на комментарий №88)
> (In reply to comment #85)
> > Должно лечиться простым удалением строки
> >     mount -o bind /run $destdir/run
> > из alterator-preinstall.
> 
> Думаешь, мы так не делали? Это первое, что предложил shaba@ -- не помогло.

  Делали или сделали? Какая на сегодняшний день обстановка на проблемной машине? Есть эта строчка или нет?

(В ответ на комментарий №74)

> Убрать #400 это всё равно, что не применить твои патчи, а откатить
> изменения shaba@, чего делать нельзя.

  В порядке эксперимента можно? mike@ уже попробовал — помогло. Попробуйте, пожалуйста, и вы. Если поможет — инсталлятор начнёт работать также, как и раньше, — то будет уже однозначно понятно, что проблема в конфликте между наличием симлинка "/var/run -> /run" и перемонтированием сокетов.

(В ответ на комментарий №91)
> (В ответ на комментарий №74)
> 
> > Убрать #400 это всё равно, что не применить твои патчи, а откатить
> > изменения shaba@, чего делать нельзя.
> 
>   В порядке эксперимента можно? mike@ уже попробовал — помогло. Попробуйте,
> пожалуйста, и вы. Если поможет — инсталлятор начнёт работать также, как и
> раньше, — то будет уже однозначно понятно, что проблема в конфликте между
> наличием симлинка "/var/run -> /run" и перемонтированием сокетов.

Я не понимаю, зачем Леонид всех путает и мешает все в одно.
mike@ откатил изменения "симлинк /var/run -> /run" на p9 для e2k.
А klark@ воюет на 8СП (x86_64), где нет никаких "симлинков /var/run -> /run".

Не смешивайте проблемы, а лучше вообще в разных багах это обсуждать.

(В ответ на комментарий №92)
> (В ответ на комментарий №91)
> > (В ответ на комментарий №74)
> > 
> > > Убрать #400 это всё равно, что не применить твои патчи, а откатить
> > > изменения shaba@, чего делать нельзя.
> > 
> >   В порядке эксперимента можно? mike@ уже попробовал — помогло. Попробуйте,
> > пожалуйста, и вы. Если поможет — инсталлятор начнёт работать также, как и
> > раньше, — то будет уже однозначно понятно, что проблема в конфликте между
> > наличием симлинка "/var/run -> /run" и перемонтированием сокетов.
> 
> Я не понимаю, зачем Леонид всех путает и мешает все в одно.
> mike@ откатил изменения "симлинк /var/run -> /run" на p9 для e2k.

Миша, попробуй тогда, пожалуйста, новую сборку preinstall без отката pkg.


> А klark@ воюет на 8СП (x86_64), где нет никаких "симлинков /var/run -> /run".
> Не смешивайте проблемы, а лучше вообще в разных багах это обсуждать.

Вот уж действительно.

(В ответ на комментарий №87)
> (In reply to comment #84)
> >   Потому что очень не верится, что если мы имеем процесс, который постоянно
> > повторяет попытки открыть файл F, то, имея в запасе время и консоль, нельзя в
> > конце концов создать ему такие условия, когда он этот файл наконец откроет.
> 
> Это история про Эльбрус. В переводе на мою ситуацию всё наоборот -- он должен,
> в конце концов, прекратить работать с прежним сокетом. Но мы на самом деле не
> знаем, почему так происходит. И как показала практика, вкорячивание задержек
> мне не помогла.

  Само по себе не помогло? Вот ты меня упорно не понимаешь или не хочешь понимать. Я сделал таймауты и повторы, в частности, для того, чтобы можно было проводить эксперименты на живой системе. Чтобы можно было поднять количество повторов до практической бесконечности и спокойно исследовать процесс прямо во время его работы — менять окружение, пробовать перемонтирование различными способами. Уже неоднократно об этом писал сюда.
  Если вдруг неудобно или не получается экспериментировать со Scheme, то можно было написать простую тестовую пару клиент-сервер и поставить её в те же самые условия, т.е. в директорию /var/run/alteratord/. Но вместо активного эксперимента, ты упорно сворачиваешь к forensic analysis и признаешь, кажется, только его. Почему — непонятно.

> > В нашем случае — откроет ту версию файла, которая нам нужна. А стоит успешно
> > закончить такой эксперимент, как всё остальное наверняка прояснится в гораздо
> > большей степени, чем сейчас.
> 
> По крайней мере, теперь у нас есть свободный экземпляр, где эта редкая проблема
> воспроизводится. И речь теперь не о локализации бага (это бы тоже не помешало,
> но мы и так убили на него слишком много времени), а речь об усовершенствовании
> механизма перехода в чрут, в целом.
> 
> Когда мы работаем с сокетом, обе стороны должны от него отключиться и удалить
> его. Также необходимо учитывать прерываемый ввод-вывод в сокете (не законченный
> ввод или вывод, прерванный в/в и возобновление после прерывания в системном
> вызове. Надеяться лишь на то, что каталог с сокетом будет перекрыт (в какой
> момент!?) и работа возобновиться через новый сокет -- в корне опрометчиво, это
> и есть архитектурный баг.

  Извини, но это вывод на пустом месте. Не зная точно и конкретно, почему директория с сокетом не перекрывается нормально, нельзя предлагать отключение от сокета в качестве лекарства. Это опять игра в угадайку. @ldv выше правильно отметил, что много лет работало. И раз теперь сломалось, значит есть конкретная причина.

(В ответ на комментарий №87)

> Когда мы работаем с сокетом, обе стороны должны от него отключиться и удалить
> его.

  Собственно, это элементарно проверить. Клиент и так не подключён к сокету — он подключается каждый раз заново. Слушает только сервер. Следовательно, пока клиент повторяет попытки, Ctrl+Alt+F2 и

    service alteratord stop
    chroot $destdir service alteratord stop
    rm -fv /var/run/alteratord/.socket
    rm -fv $destdir/var/run/alteratord/.socket
    chroot $destdir service alteratord start

> Также необходимо учитывать прерываемый ввод-вывод в сокете (не законченный
> ввод или вывод, прерванный в/в и возобновление после прерывания в системном
> вызове.

  Учитывать это как? Напиши конкретнее, что ты имеешь в виду.

У нас есть два немного отличающихся проявления одной и той же проблемы: alterator не может перейти к следующему шагу в чруте после шага alterator-pkg. mike@ просил описать в ЭТОМ баге, как я на это нарвался. Если есть желание разделить ЕГО на два отдельных бага и это целесообразно, давайте разделим.

Путается кто-то другой -- я довольно чётко описываю, в каких ситуациях это проявляется на старом образе 8СП в режиме загрузки UEFI/x86_64. Конечно, с e2k я не работаю. Но моё предложение заключалось в том, чтобы после усовершенствования механизма перехода в чрут применить данное решение к обеим случаям, т.е. и к e2k тоже, а не заниматься локализацией проблемы, на которую убито и так слишком много времени.

Относительно продолжения работ по данному багу ещё разок поясню:

1) Всё что можно было исследовать в части бэкэнда -- я сделал, нашёл кучу ошибок и даже частично их описал. Но даже с ними это как-то на удивление работало годами. Поэтому их исправление сейчас -- не первая необходимость.

2) Со схемой и фронт-эндом в любом случае ничем помочь не могу.

3) Временной лимит на данную задачу для меня исчерпан -- cas@ и smi@ ставят другие более срочные сейчас задачи. Поэтому данная задача передана manowar@.

4) С руководством пока окончательно не согласовано, но в офисе МСК нашёлся системный блок, где проблема проявляется. Его можно переправить manowar@. Удалённо выполнять в МСК на нём какие-то действия сейчас просто некому.

По частностям:

1) service alteratord stop -- после этого инсталлятор зависнет, ни к какому другому шагу он больше не перейдёт. Ещё раз: больше недели всё что на шелле, я перелопатил и опробовал всё.

2) "Попробуйте, пожалуйста, и вы." -- mike@ пересобирает новые образы, а здесь как предлагалось? Очень большой объём изменений вносить через vi в старый образ 8СП! Как ты себе это представляешь?

3) "Миша, попробуй тогда, пожалуйста, новую сборку preinstall без отката pkg." -- он пока в отпуске.

(В ответ на комментарий №96)

> 4) С руководством пока окончательно не согласовано, но в офисе МСК нашёлся
> системный блок, где проблема проявляется. Его можно переправить manowar@.

  Я не против, конечно.

> 1) service alteratord stop -- после этого инсталлятор зависнет, ни к какому
> другому шагу он больше не перейдёт. Ещё раз: больше недели всё что на шелле, я
> перелопатил и опробовал всё.

  Ты уверен, что тут именно зависание? Может быть ты просто количество повторов настроил очень большим? Потому что после истечения заданного количества повторов, инсталлятор должен закончить работу с ошибкой.
Может быть это и в самом деле другая ошибка, как shaba@ писал.

(In reply to comment #97)
> Ты уверен, что тут именно зависание?

В моём случае на 8СП на проблемных экземплярах это так и этому можно найти некое объяснение. Ведь там работа продолжается со старым сокетом, как уже выяснили. И тут мы такие смелые приходим во вторую консоль и его отрубаем. А морда инсталлятора продолжает работать...

Конечно, вызывает недоумение, а как раньше-то этот ныне закомментированный код работал? Очевидно, также, как и остальной код, где есть ошибки -- пока не словили гонки, на это никто не напарывался.

Нам ещё привозили третий Ryzen из ICL. Там тоже этот баг проявлялся, но машину уже отдали.

(В ответ на комментарий №98)
> (In reply to comment #97)
 
> Конечно, вызывает недоумение, а как раньше-то этот ныне закомментированный код
> работал?

  Ты вот об этом backend3/preinstall?

    # stop old alteratord and kill itself
    # sleep 1
    # service alteratord stop

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

  Но я имел в виду не автоматический service alteratord stop, а именно вручную из второй (третьей и т.д.) консоли. Причём не абы когда...

> В моём случае на 8СП на проблемных экземплярах это так и этому можно найти
> некое объяснение. Ведь там работа продолжается со старым сокетом, как уже
> выяснили. И тут мы такие смелые приходим во вторую консоль и его отрубаем. А
> морда инсталлятора продолжает работать...

...а тогда, когда клиент уже выйдет на режим (!) повторов и начнёт писать в лог Retry #1, Retry #2... Тогда будет ясно, что он уже _не продолжает_ работать со старым сокетом, а делает только пыпытки начать работу с сокетом — а это не одно и то же. В таком состоянии service alteratord stop не должен повлиять на ситуацию в худшую сторону.

Тут очень запутанное обсуждение, особенно тяжело что-то понять из-за того, что manowar@ пишет разные предложение: попробуйте так, или вот так, и т.д. А в ответ нет отчётов о том, попробовали или нет и как это изменило поведение.

Т.е. непонятно: тому, кто будет ещё этим заниматься, пробовать что-то новенькое или то, что предлагал manowar@?

К тому же Леонид мне рассказал, что у него есть две флешки:

* синяя "ALT 8 SP FSTEK" -- где это воспроизводится на некоторых системных блоках, с которыми он работает;
* жёлтая, условно назовём её ALT 8.1 SP -- где это не воспроизводится!

Интересно, какое ещё решение это проблемы нажо искать, если с жёлтой флешкой ФДЕ 8.1 SP она уже не воспроизводится...

В таком случае остаётся для начала по крайней мере сделать очередной "forensic analysis" и посмотреть, что отличается в образах на этих двух флешках (или что отличается в пакетах, которые туда попали, в том состоянии репозитория, когда эти образы делались).

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

(In reply to comment #100)

> К тому же Леонид мне рассказал, что у него есть две флешки:
> 
> * синяя "ALT 8 SP FSTEK" -- где это воспроизводится на некоторых системных
> блоках, с которыми он работает;
> * жёлтая, условно назовём её ALT 8.1 SP -- где это не воспроизводится!
> 
> Интересно, какое ещё решение это проблемы надо искать, если с жёлтой флешкой
> ALT 8.1 SP она уже не воспроизводится...
> 
> В таком случае остаётся для начала по крайней мере сделать очередной "forensic
> analysis" и посмотреть, что отличается в образах на этих двух флешках (или что
> отличается в пакетах, которые туда попали, в том состоянии репозитория, когда
> эти образы делались).

Леонид, поправь, если что-то не так понял и передал.

А когда и кем эти образы делались? Можно ли просто посмотреть на состав пакетов в них?

Ещё интересное замечание, рассказаное Леонидом (поправь, если не так понял), которого здесь не было написано:

на системных блоках x86_64, где у него наблюдается проблема, она наблюдается только при устанвке в EFI режиме, но не legacy.

(В ответ на комментарий №100)
> Тут очень запутанное обсуждение, особенно тяжело что-то понять из-за того, что
> manowar@ пишет разные предложение: попробуйте так, или вот так, и т.д. А в
> ответ нет отчётов о том, попробовали или нет и как это изменило поведение.

  Да, это боль.

> Т.е. непонятно: тому, кто будет ещё этим заниматься, пробовать что-то новенькое
> или то, что предлагал manowar@?
> 
> К тому же Леонид мне рассказал, что у него есть две флешки:
> 
> * синяя "ALT 8 SP FSTEK" -- где это воспроизводится на некоторых системных
> блоках, с которыми он работает;
> * жёлтая, условно назовём её ALT 8.1 SP -- где это не воспроизводится!
> 
> Интересно, какое ещё решение это проблемы нажо искать, если с жёлтой флешкой
> ФДЕ 8.1 SP она уже не воспроизводится...

  Скажу, что согласен с Леонидом в одном: что нужно найти не workaround, а истинный корень проблемы — такое место, которое провоцирует нестабильность и ненадёжность при переходе в чрут (и иногда вот проявляется как ошибка), и исправить его. Но я не согласен принимать на веру, что это "mount -o bind" плохо работает или что это доменные сокеты подкачали и отказываться от данного механизма на таком "основании".

(В ответ на комментарий №100)
> Тут очень запутанное обсуждение, особенно тяжело что-то понять из-за того, что
> manowar@ пишет разные предложение: попробуйте так, или вот так, и т.д. А в
> ответ нет отчётов о том, попробовали или нет и как это изменило поведение.
> 
> Т.е. непонятно: тому, кто будет ещё этим заниматься, пробовать что-то новенькое
> или то, что предлагал manowar@?
> 
> К тому же Леонид мне рассказал, что у него есть две флешки:
> 
> * синяя "ALT 8 SP FSTEK" -- где это воспроизводится на некоторых системных
> блоках, с которыми он работает;
> * жёлтая, условно назовём её ALT 8.1 SP -- где это не воспроизводится!
> 
> Интересно, какое ещё решение это проблемы нажо искать, если с жёлтой флешкой
> ФДЕ 8.1 SP она уже не воспроизводится...
> 
> В таком случае остаётся для начала по крайней мере сделать очередной "forensic
> analysis" и посмотреть, что отличается в образах на этих двух флешках (или что
> отличается в пакетах, которые туда попали, в том состоянии репозитория, когда
> эти образы делались).
> 
> Придумывать что-то новенькое, когда ещё даже неизвестно, почему с желтой
> флешкой проблема исчезла -- странное занятие.

+1

(In reply to comment #11)

> > А как же alterator-wait из того же самого скрипта?
> 
> Обязан, но не ждёт. Перезапуск инсталлятора после падения в моём случае с 8СП
> говорит о том, что alteratord в целевой системе запустился, то есть,
> alterator-wait должным образом не работает либо из-за занятости вводом/выводом
> к моменту его вызова не происходит удаления старого сокета. Позже --
> происходит.
> 
> Первый sleep вроде как должен помочь в случае с e2k, вот только какой? Ни 2, ни
> 5, ни 180 секунд нам не помогли. Второй sleep вкорячивали перед alterator-wait
> -- второй как раз наш случай с 8СП на x86_64, сегодня с этой машиной последний
> день можем работать.

А во втором случае sleep прямо перед aletarator-wait в скрипте preinstall не помогал (на 8СП на x86_64)?

Из сообщений не очень понятно.

Имеется в виду после запуска alteratord в чруте и перед alterator-wait.

Иван описал переданную ситуацию совершенно верно. Но насчёт EFI это замечание выше озвучивалось несколько раз -- на x86_64 это проявляется только в EFI, но не в Legacy. Я даже уточню, хотя с этим багом не связано. На четырёх физических экземплярах есть видеокарта Intel (PCI 0:2:0), на Ryzen'е была видеокарта AMD Vega. На всех пяти машинах число падений инсталлятора в режиме Legacy -- 0, в режиме EFI -- 2 падения. Первое падение здесь offtop, оно связано с ошибкой в инсталляторе при определении видеокарты. Давно исправлено во всех бранчах, но не в старых образах. Второй раз инсталлятор падает уже в середине работы, уже после первого перезапуска.

А вот насчёт этого -- в точку!

(In reply to comment #103)
> 
>   Скажу, что согласен с Леонидом в одном: что нужно найти не workaround, а
> истинный корень проблемы — такое место, которое провоцирует нестабильность и
> ненадёжность при переходе в чрут (и иногда вот проявляется как ошибка), и
> исправить его. Но я не согласен принимать на веру, что это "mount -o bind"
> плохо работает или что это доменные сокеты подкачали и отказываться от данного
> механизма на таком "основании".

Мне удалось через пень-колоду применить ранее озвученный workaround. Не сразу. А в процессе опять же strace'ом пытался понять, почему не запускается, что мешает. И вот тут выяснилась совсем новая интересная информация...

Ранее мы исходили из того, что раз после падения работает alterator-cmdline, раз инсталлятор запускается повторно, с сокетом всё нормализовалось. И мы были уверены, что проблема с механизмом перехода в чрут. Но оказалось, что с переходом в чрут нет проблем, их нет и с сокетом. Как будто ошибка в самом шаге grub и единственное, что помогло, это копирование тех файлов, что он не может найти, в обе стороны. Я опишу потом подробнее всю схему.

(In reply to comment #105)
> (In reply to comment #11)
> 
> > > А как же alterator-wait из того же самого скрипта?
> > 
> > Обязан, но не ждёт. Перезапуск инсталлятора после падения в моём случае с 8СП
> > говорит о том, что alteratord в целевой системе запустился, то есть,
> > alterator-wait должным образом не работает либо из-за занятости вводом/выводом
> > к моменту его вызова не происходит удаления старого сокета. Позже --
> > происходит.
> > 
> > Первый sleep вроде как должен помочь в случае с e2k, вот только какой? Ни 2, ни
> > 5, ни 180 секунд нам не помогли. Второй sleep вкорячивали перед alterator-wait
> > -- второй как раз наш случай с 8СП на x86_64, сегодня с этой машиной последний
> > день можем работать.
> 
> А во втором случае sleep прямо перед aletarator-wait в скрипте preinstall не
> помогал (на 8СП на x86_64)?
> 
> Из сообщений не очень понятно.
> 
> Имеется в виду после запуска alteratord в чруте и перед alterator-wait.

Мне было интересно и я именно это попробовал на x86_64: sleep 60 в начале d-wait. Не исправляет проблему, то же самое.

(In reply to comment #106)
> ...опишу потом подробнее всю схему.

Если в /usr/lib/alterator/backend3/preinstall сразу после запуска альтератора в чруте (перед alterator-wait) добавить такие строчки:

cp -Lf  /usr/share/install2/installer-steps $destdir/usr/share/install2/
cp -LRf /usr/share/install2/steps $destdir/usr/share/install2/
cp -LRf /usr/share/alterator/design/images/steps \
        $destdir/usr/share/alterator/design/images/
cp -Lf  /usr/lib/alterator/backend3/step-list \
        $destdir/usr/lib/alterator/backend3/
cp -LRf /usr/share/alterator/ui/wizard $destdir/usr/share/alterator/ui/
cp -LRf $destdir/usr/share/alterator/ui/* /usr/share/alterator/ui/

инсталлятор больше не падает, успешно переходит к шагу grub и далее доходит до самого конца. Проблема ровно в том месте, на которое я указывал ранее. Данный workaround позволяет не дойти до места возникновения этой ошибки в одном из включаемых скриптов гайла в alterator-wizard.

Пожалуй, дополню: безусловно проблему решает лишь последнее копирование:

cp -LRf $destdir/usr/share/alterator/ui/* /usr/share/alterator/ui/

(перед alterator-wait). Пять других нужны были лишь на случай падения инсталлятора и там ещё нужно было делать до них что-то вроде:

sed -i '1,/^installer\-preinstall/d' /usr/share/install2/installer-steps

где installer-preinstall -- последний успешно выполненный шаг. А раз инсталлятор больше не падает, то вроде как и не нужны уже первые пять копирований. Сейчас я эту версию проверяю...

Таким образом, уже можно сделать выводы на предмет того, что именно искать в части отличий. В новом коде добавлен поиск по путям с префиксом /mnt/destination -- шесть вызовов stat(), а не четыре. Но если этот код был и раньше, значит падает не дойдя до него, не перебрав все варианты. И в процессе этой ошибки нет каких-либо других системных вызовов, она чисто логическая, в коде guile.

Поясню по последнему абзацу. Вот так выглядит сбой в плохом случае:

stat("/usr/share/alterator/ui//grub/index.scm", 0x7ffc052c6520) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/ui//grub.scm", 0x7ffc052c65a0) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub/index.scm", 0x7ffc052c65a0) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub.scm", 0x7ffc052c6620) = -1 ENOENT (No such file or directory)
write(1, "<* ((#t))\nRET: ()\n", 18) = 18

В хорошем случае вывод starce отличается, начиная с 5-й строки:

stat("/usr/share/alterator/ui//grub/index.scm", 0x7ffe90f1d3e0) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/ui//grub.scm", 0x7ffe90f1d460) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub/index.scm", 0x7ffe90f1d460) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub.scm", 0x7ffe90f1d4e0) = -1 ENOENT (No such file or directory)
stat("/mnt/destination/usr/share/alterator/ui//grub/index.scm", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
access("/mnt/destination/usr/share/alterator/ui//grub/index.scm", R_OK) = 0
open("/mnt/destination/usr/share/alterator/ui//grub/index.scm", O_RDONLY) = 15

Но в случае сбоя до обращения к /mnt/destination/usr/share/alterator/ui//grub/index.scm дело не доходит. workaround превратит этот вывод во что-то такое:

stat("/usr/share/alterator/ui//grub/index.scm", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
access("/usr/share/alterator/ui//grub/index.scm", R_OK) = 0
open("/usr/share/alterator/ui//grub/index.scm", O_RDONLY) = 15

На всякий случай напомню предысторию: до шага /grub альтератор стучался по четырём путям для каждого шага и по одному из них находил искомое. Это логично, поскольку все необходимые файлы для первых шагов должны лежать в установочной системе. Но файлов морды для шагов, выполняемых в чруте, в установочной системе нет. Вот здесь по факту тоже всегда пусто:

ls /usr/share/alterator/templates/
ls /mnt/destination/usr/share/alterator/templates/

Если скопировать из чрута в установочную систему UI-файлы только для шага /grub, инсталлятор вылетит на следующем шаге -- /net, итд... Почему он не ищет их в чруте, почему он не доходит до /mnt/destination/usr/share/alterator/ui//grub/index.scm -- не знаю.

Леонид, а может быть, две последовательные ошибки на x86_64 с ALT SP 8 -- связанные вещи?

В legacy-режиме вторая не происходит. А первая, с запуском X-сервера происходит?

Просто я подумал, прочитав твоё последнее сообщение, что когда ты вручную после первой ошибки запускаешь xinit /usr/sbin/alterator-install2, ты, чозможно, теряешь для него параметры или переменные окружения, который добавляют пути для поиска scm-файлов интерфейса шагов.

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

(In reply to comment #111)
> Леонид, а может быть, две последовательные ошибки на x86_64 с ALT SP 8 --
> связанные вещи?

Думал об этом -- исключено. Первый баг был обнаружен более 2х лет назад и исправлен более года назад. Ещё раньше я начал применять workaround с fbdev на EFI. Машин с тех пор через меня прошло очень много и ни одна из них второй раз не вываливалась в середине. Первая такая машина появилась совсем недавно -- Ryzen из ICL, но тогда мы грешили на совсем плохое железо.

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

(В ответ на комментарий №110)

> Если скопировать из чрута в установочную систему UI-файлы только для шага
> /grub, инсталлятор вылетит на следующем шаге -- /net, итд... Почему он не ищет
> их в чруте, почему он не доходит до
> /mnt/destination/usr/share/alterator/ui//grub/index.scm -- не знаю.

  Слушай, но это же очевидно. Искать что-то в /mnt/destination/usr/share/... может только процесс alteratord, работающий _вне_ чрута /mnt/destination, т.е. исходный, первый процесс alteratord. Идея же перехода в чрут заключаается в том, что внутри чрута запускается свой, отдельный alteratord, для которого файл /mnt/destination/usr/share/alterator/ui//grub/index.scm превращается просто в /usr/share/alterator/ui//grub/index.scm. Подкладывать файлы в чрут как делаешь ты — это значит продолжать ехать на первом экземпляре alteratord, а не на втором.

  И следовательно, сказанное тобой в №110 неверно:

(В ответ на комментарий №110)

> Ранее мы исходили из того, что раз после падения работает alterator-cmdline,
> раз инсталлятор запускается повторно, с сокетом всё нормализовалось. И мы были
> уверены, что проблема с механизмом перехода в чрут. Но оказалось, что с
> переходом в чрут нет проблем, их нет и с сокетом.

  Проблема с переключением на сокет второго экземпляра alteratord есть. Может быть даже есть проблема с запуском этого второго экземпляра.

Падает процесс alterator-wizard, морда альтератора. Это следует из отладочных журналов. Причина падения -- неизвестна. В нормальной ситуации, падения не происходит по той причинеТвоё утвер

Падает процесс alterator-wizard, морда альтератора. Это следует из отладочных журналов. Я же подключался ко всем активным процессам. Причина падения -- неизвестна. В нормальной ситуации, падения не происходит по той причине, что wizard продолжает поиск в /mnt/destianation. Можешь взять starce и попробовать на любом дистрибутиве, даже необязательно на 8СП.

Твоё утверждение ошибочно потому, что морда, в отличии от демона, в чрут не переходит. Но шаги (фронтэнд) она видеть должна. Она знает, где их искать на диске. Поскольку между установочной системой и целевой они разнесены, она должна искать их и там, и здесь. Но находит в /mnt/destination лишь когда нет рейса, в 99.99% случаев.

Твоя задача как раз понять, где ошибка в guile-логике перебора этих путей. Смотри внимательно на вывод strace. Если бы дело обстояло, как ты говоришь, команда копирования UI-файлов проблему бы не решила. Потому что файлы бэкэнда остались в чруте и с ними работает новый экземпляр демона по перекрытому сокету.

(В ответ на комментарий №115)

> Твоё утверждение ошибочно потому, что морда, в отличии от демона, в чрут не
> переходит. Но шаги (фронтэнд) она видеть должна.

  Согласен. Я и забыл, что это именно морда. Но тогда встречный вопрос: может быть установочный образ должен просто содержать /usr/share/alterator/ui для всех модулей, как внешних, так и чрутных? Т.е. при подготовке образа инсталлятора нужно ставить все задействованные пакеты alterator-*, а не только половину? Если у нас для legacy и UEFI два разных образа корневой ФС, то это вполне возможная ошибка.

(In reply to comment #116)
> Но тогда встречный вопрос: может
> быть установочный образ должен просто содержать /usr/share/alterator/ui для
> всех модулей, как внешних, так и чрутных?

Это бы решило проблему. Но не думаю, что это единственное верное решение, ведь редко проявляющаяся ошибка в логике останется в коде. Сейчас мы проверяем на друхих железках x86_64/EFI, хорошо бы проверить и на e2k.

> Т.е. при подготовке образа
> инсталлятора нужно ставить все задействованные пакеты alterator-*, а не только
> половину? Если у нас для legacy и UEFI два разных образа корневой ФС, то это
> вполне возможная ошибка.

Я проверил -- на старых образах 8СП шаги разнесены. От Legacy/EFI не зависит, это в сквоше /altinst. И не только в сквоше, оно и на живой системе так к моменту открытия, скажем, второго шага.

Created attachment 8310 [details]
Исправленный preinstall

Created attachment 8311 [details]
Исправлятор проблемы на 8СП x86_64/EFI

Фикса для 8СП помещается на чистую флэшку вместе с исправленным preinstall. При первом падении даём всего две команды:

mount /dev/sdc1 /mnt
/mnt/fix

После этого инсталлятор запускается в графике и больше не падает, сразу выдёргиваем флэшку с фиксой. Установка успешно проходит до конца -- проверили на нескольких проблемных машинах. Учёл замечания Ивана на предмет переменной окружения DURING_INSTALL -- без неё не очень хорошо всё отрабатывало в скрипте postinstall.

(In reply to comment #115)
> Падает процесс alterator-wizard, морда альтератора. Это следует из отладочных
> журналов. Я же подключался ко всем активным процессам. Причина падения --
> неизвестна. В нормальной ситуации, падения не происходит по той причине, что
> wizard продолжает поиск в /mnt/destianation. Можешь взять starce и попробовать
> на любом дистрибутиве, даже необязательно на 8СП.
> 
> Твоё утверждение ошибочно потому, что морда, в отличии от демона, в чрут не
> переходит. Но шаги (фронтэнд) она видеть должна. Она знает, где их искать на
> диске. Поскольку между установочной системой и целевой они разнесены, она
> должна искать их и там, и здесь. Но находит в /mnt/destination лишь когда нет
> рейса, в 99.99% случаев.

Я тоже так считаю.

> Твоя задача как раз понять, где ошибка в guile-логике перебора этих путей.
> Смотри внимательно на вывод strace. Если бы дело обстояло, как ты говоришь,
> команда копирования UI-файлов проблему бы не решила. Потому что файлы бэкэнда
> остались в чруте и с ними работает новый экземпляр демона по перекрытому
> сокету.

(In reply to comment #111)
> Леонид, а может быть, две последовательные ошибки на x86_64 с ALT SP 8 --
> связанные вещи?
> 
> В legacy-режиме вторая не происходит. А первая, с запуском X-сервера
> происходит?
> 
> Просто я подумал, прочитав твоё последнее сообщение, что когда ты вручную после
> первой ошибки запускаешь xinit /usr/sbin/alterator-install2, ты, чозможно,
> теряешь для него параметры или переменные окружения, который добавляют пути для
> поиска scm-файлов интерфейса шагов.

Всё действительно так.

/usr/sbin/install2 экспортирует переменную окружения GUILE_LOAD_PATH, в которую добавлены дополнительные пути в /mnt/destination/

Также я проверил, что попытка запуска или редактирования xorg.conf в /usr/sbin/install2 делается без затирания того, что есть.

Так что, чтобы успешно сделать установку на этих x86_64 компах, делаем так:

когда первый раз выпадаем из-за X-ов, конфигурируем их так, как сказано здесь -- https://forum.altlinux.org/index.php?topic=42871.msg340856#msg340856 , например:

# lspci | fgrep VGA
...смотрим номер, меняем точку на двоеточие
# cat >/etc/X11/xorg.conf
Section "Device"
  Identifier "Card0"
  Driver "fbdev"
  BusID "PCI:00:02:0"
EndSection

и запускаем в первой консоли этот целый скрипт обёртку:

# /usr/sbin/install2

(Он, правда, заново стартует всякие преинсталл-сервисы, но это не мешает успешной установке дальше.) В конце он должен выполнить postinstall-скрипты.
И если дальше нажать Ctrl-D в этом шелле (предварительно, я ещё на других консолях нажал Ctrl-D), то он всё размонтирует и перезагружается.

Это было описание первого способа.

2-ой способ (который, возможно, объясняет, почему в прошлом Леонид сталкивался с первой ошибкой, но не второй):

xorg.conf делаем так же.

А в shell-е на второй консоли на самом деле уже выставлена другая переменная окружения, с таким же хорошим эффектом: ALTERATOR_DATADIR

Там можно вручную запустить, как Леонид:

xinit /usr/sbin/alterator-install2 -- vt7 -dpms -ac \
        -nolisten tcp -logfile /tmp/x11.log >> /tmp/install2.log 2>&1

И установка тоже пройдёт успешно, но в конце не будут выполнены postinstall-скрипты. (Надо вручную запустить.)

Это был 2-ой способ.

1-ый и 2-ой способ можно комбинировать по вкусу.

Плохой ситуации на e2k в образах более свежих, чем 8.1, это никак не затрагивает (и не решает). Но для той ситуации manowar@ высказал много полезных предложений, которые помогут её решить или выяснить, в чём дело.

Created attachment 8312 [details]
Исправлятор проблемы на 8СП x86_64/EFI #2

(In reply to comment #121)
> (In reply to comment #111)
> > Леонид, а может быть, две последовательные ошибки на x86_64 с ALT SP 8 --
> > связанные вещи?
> > 
> Всё действительно так.
> 

Конечно жаль, что убили на такую фигню столько времени. Зато теперь для моего случая есть аж целых три воркэраунда!

> Это был 2-ой способ.

Всё-таки третий. Я его проверил и автоматизировал. Теперь при вылете на графике в режиме EFI достаточно переключиться на вторую консоль, смонтировать флэшку, запустить с неё этот fix2. А когда инсталлятор запустится, флэшку с фиксой выдернуть.

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

Возможно, причастно (в e2k-репозиториях не было версий новее 2.3.16
с патчиком насчёт lib32):

$ rpm -qp --lastchange filesystem-2.3.17-alt1.src.rpm 
* Вт авг 28 2018 Dmitry V. Levin <ldv@altlinux.org> 2.3.17-alt1
- Moved /etc/syslog.d from syslog-common to filesystem.
- Made /lib/modules readable and executable by everybody (closes: #5969).
- Added libx32 directories on x86_64 and x32 systems (by Ivan Zakharyaschev).
- Added lib32 directories on %e2k (thx Ivan Zakharyaschev).
- Added %ghost /run/lock/, marked /var/lock/ and /var/lock/* as %ghost
  (by Alexey Shabalin).

Есть ли здесь какое-то общее решение, которое нужно внести в альтератор или инсталлер? Кажется, нет.

(In reply to comment #124)
> Есть ли здесь какое-то общее решение, которое нужно внести в альтератор или
> инсталлер? Кажется, нет.

Что касается той проблемы, с которой Леонид столкнулся (из-за можно так сказать невнимательности или неполных знаний), то было бы яснее людям, если бы дополнительный путь передавался не через переменную окружения GUILE_LOAD_PATH (на которую легко не обратить внимание при изучении работы), а явно в виде аргумента командам alterator-а.

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