35350 2018-09-05 18:20:26 +0300 Нет директории /var/lock/subsys/ на sysV 2023-07-02 17:41:58 +0300 1 1 4 Development Sisyphus systemd-utils unstable all Linux CLOSED NOTABUG https://bugzilla.altlinux.org/show_bug.cgi?id=35881 regression P3 critical --- 1 antohami shaba aen evg glebfm klark.devel ldv mike sem shaba zxwarior qa-sisyphus oldest_to_newest 173923 0 antohami 2018-09-05 18:20:26 +0300 После последнего обновления filesystem в регулярках на sysV нет директории /var/lock/subsys/ В результате многие службы жалуются, что не могут создать lock файл в этой директории. Проблема вызвана вот этим коммитом ориентировочно: http://git.altlinux.org/people/ldv/packages/?p=filesystem.git;a=commitdiff;h=ab242a12ddb4d29fbc6523d0bb5bdf584c31ef12 Я так понимаю, что директории должны создаваться в tmpfs, на на sysV создаётся только /var/lock/ а директорий: %attr(0700,root,root) %dir /var/lock/subsys %ghost %attr(0770,root,uucp) %dir /var/lock/uucp %ghost %attr(0770,root,uucp) %dir /var/lock/serial %ghost нет. Проблема, как на live, так и установленной системе. 173924 1 mike 2018-09-05 18:23:34 +0300 ...и это ещё одна проблема, которую можно было поймать на тестовых регулярках, а не разломав мне сизиф в самый неудобный для того по нагрузке момент. Просьба в будущем не стесняться запросить сборку/проверку. 173926 2 shaba 2018-09-05 21:13:43 +0300 Хотелось бы понять, почему у вас не отрабатывает tmpfiles? В конфиге /lib/tmpfiles.d/legacy.conf присутствует: d /run/lock/subsys 0700 root root - Точнее, хотелось бы понять, почему у вас /run не тоже самое что и /var/run 173927 3 shaba 2018-09-05 21:14:35 +0300 извиняюсь, почему /var/lock не тоже самое что /run/lock 173928 4 antohami 2018-09-06 07:41:24 +0300 (В ответ на комментарий №3) > извиняюсь, почему /var/lock не тоже самое что /run/lock /run/lock отсутствует совсем в rescue (какого-то пакета в сборке не хватает? или директории в /run создаются по требованию?) А в остальных (icewm, wmaker, gnustep, jeos) /run/lock отличается от /var/lock содержимым, т.е. да, не тоже самое. Также не тоже самое /var/run и /run Какой пакет отвечает за отработку правил /lib/tmpfiles.d/ ? Конфиг /lib/tmpfiles.d/legacy.conf присутствует, принадлежит пакету systemd-utils. 173973 5 antohami 2018-09-08 10:42:47 +0300 (В ответ на комментарий №4) > Какой пакет отвечает за отработку правил /lib/tmpfiles.d/ ? systemd-tmpfiles из пакета systemd-utils. Для sysV нужен инит-скрипт для него. 173974 6 ldv 2018-09-08 10:58:24 +0300 (In reply to comment #5) > (В ответ на комментарий №4) > > Какой пакет отвечает за отработку правил /lib/tmpfiles.d/ ? > > systemd-tmpfiles из пакета systemd-utils. Для sysV нужен инит-скрипт для него. Этот скрипт традиционно называется /etc/rc.d/scripts/cleanup, вызывается из /etc/rc.d/rc.sysinit; так что перевешиваю на systemd-utils. 173979 7 antohami 2018-09-08 15:44:36 +0300 (В ответ на комментарий №6) > (In reply to comment #5) > > (В ответ на комментарий №4) > > > Какой пакет отвечает за отработку правил /lib/tmpfiles.d/ ? > > > > systemd-tmpfiles из пакета systemd-utils. Для sysV нужен инит-скрипт для него. > > Этот скрипт традиционно называется /etc/rc.d/scripts/cleanup, вызывается из > /etc/rc.d/rc.sysinit; так что перевешиваю на systemd-utils. Спасибо за информацию. Но так как на systemd всё работает, а на sysV нет, то логично предположить, что дело всё-таки в /etc/rc.d/scripts/cleanup из пакета startup. Проблема то похоже давнишняя. На sysV отличаются директории /var/run/ и /run/ уже очень давно. На июньском стартеркитe (p8) директории также не одно и тоже. Может из /etc/rc.d/scripts/cleanup как-то неправильно вызывает systemd-tmpfiles? Или не тогда, когда надо? 174026 8 ldv 2018-09-11 03:44:16 +0300 (In reply to comment #7) > (В ответ на комментарий №6) > > (In reply to comment #5) > > > (В ответ на комментарий №4) > > > > Какой пакет отвечает за отработку правил /lib/tmpfiles.d/ ? > > > > > > systemd-tmpfiles из пакета systemd-utils. Для sysV нужен инит-скрипт для него. > > > > Этот скрипт традиционно называется /etc/rc.d/scripts/cleanup, вызывается из > > /etc/rc.d/rc.sysinit; так что перевешиваю на systemd-utils. > > Спасибо за информацию. Но так как на systemd всё работает, а на sysV нет, то > логично предположить, что дело всё-таки в /etc/rc.d/scripts/cleanup из пакета > startup. Проблема то похоже давнишняя. На sysV отличаются директории /var/run/ > и /run/ уже очень давно. На июньском стартеркитe (p8) директории также не одно > и тоже. Дело, конечно, не в /etc/rc.d/scripts/cleanup; /var/run в /lib/tmpfiles.d/legacy.conf вообще нет, а почему правило для /var/lock не выполняется, это тоже к systemd-utils. Мне кажется, что systemd c некоторых пор обрабатывает /var/run и /var/lock особым образом, что ломает наши правила в /lib/tmpfiles.d/legacy.conf > > Может из /etc/rc.d/scripts/cleanup как-то неправильно вызывает > systemd-tmpfiles? Или не тогда, когда надо? 174608 9 antohami 2018-09-30 18:59:12 +0300 Причина нашлась: https://forum.altlinux.org/index.php?topic=36177.msg330926#msg330926 Коротко. В /lib/tmpfiles.d/legacy.conf строка L /var/lock - - - - ../run/lock не отрабатывает, но зато отрабатывает, если добавить плюсик: L+ /var/lock - - - - ../run/lock Плюсик означает, что каталог заменяется на симлинк даже, если внутри него есть файлы. Другой вопрос почему не отрабатывает именно на sysV, а на systemd всё отрабатывает? В initrd, кстати, есть /var/lock/subsys. Наверное он нужен для udev в самом initrd. Изменит ли как-то ситуацию удаление директории /var/lock/subsys из initrd? Ещё одна версия, что какой-то демон чего-то успел записать в /var/lock, также не нашла подтверждения у меня. В этом случае должны были остаться какие-то следы от него, чего нет в /var/lock. Может добавим плюсик? Проблема с /var/run также решается добавлением плюсика в /lib/tmpfiles.d/var.conf в строку: L /var/run - - - - ../run 174613 10 zxwarior 2018-10-01 11:56:57 +0300 (В ответ на комментарий №9) > Причина нашлась: > https://forum.altlinux.org/index.php?topic=36177.msg330926#msg330926 > > Коротко. В /lib/tmpfiles.d/legacy.conf строка > > L /var/lock - - - - ../run/lock > > не отрабатывает, но зато отрабатывает, если добавить плюсик: > L+ /var/lock - - - - ../run/lock > > ... > > Может добавим плюсик? Проблема с /var/run также решается добавлением плюсика в > /lib/tmpfiles.d/var.conf в строку: > L /var/run - - - - ../run Оттестировал перевод лайва (лайв-режим) http://nightly.altlinux.org/sisyphus/snapshots/20180926/regular-xfce-20180926-i586.iso с systemd на sysvinit. Последовательность действий: Сменить L на L+ $ grep ^L /lib/tmpfiles.d/legacy.conf L+ /var/lock - - - - ../run/lock Установить пакеты для перевода регулярного лайва xfce с systemd на sysvinit # apt-get install \ sysvinit \ pm-utils \ nm-sysvinit \ polkit-sysvinit \ systemd- \ systemd-services- \ systemd-sysvinit- \ apt-conf-ignore-systemd \ syslog-ng Перезагрузиться по SysRq Alt+Fn+SysRq+SUB После перезагрузки получаем в лайве # ls -l /proc/1/exe lrwxrwxrwx 1 root root 0 окт 1 14:27 /proc/1/exe -> /sbin/init # ls -l /{var,run} | grep lock drwxr-xr-x 6 root root 120 окт 1 14:27 lock lrwxrwxrwx 1 root root 11 окт 1 14:27 lock -> ../run/lock # find /{var,run}/lock -type f -print /run/lock/subsys/plymouth /run/lock/subsys/alteratord /run/lock/subsys/ntpd /run/lock/subsys/spice-vdagentd /run/lock/subsys/avahi /run/lock/subsys/autofs /run/lock/subsys/dm /run/lock/subsys/keytable /run/lock/subsys/fbsetfont /run/lock/subsys/udevd-final /run/lock/subsys/sensors /run/lock/subsys/random /run/lock/subsys/bluetooth /run/lock/subsys/NetworkManager /run/lock/subsys/network /run/lock/subsys/messagebus /run/lock/subsys/acpid /run/lock/subsys/udevd # ls -l /{var,run}/lock lrwxrwxrwx 1 root root 11 окт 1 14:27 /var/lock -> ../run/lock /run/lock: итого 0 drwx------ 2 root root 40 окт 1 14:27 lvm drwxr-xr-x 2 root root 40 окт 1 14:27 sepermit drwxrwx--- 2 root uucp 40 окт 1 14:27 serial drwx------ 2 root root 400 окт 1 14:27 subsys Плюс получаем отсутствие ошибки No such file or directory на загрузке на предмет subsys, при создании lock-файла. 174722 11 shaba 2018-10-03 17:59:34 +0300 (В ответ на комментарий №9) > L /var/lock - - - - ../run/lock > > не отрабатывает, но зато отрабатывает, если добавить плюсик: > L+ /var/lock - - - - ../run/lock > > Плюсик означает, что каталог заменяется на симлинк даже, если внутри него есть > файлы. > > Другой вопрос почему не отрабатывает именно на sysV, а на systemd всё > отрабатывает? > > В initrd, кстати, есть /var/lock/subsys. Наверное он нужен для udev в самом > initrd. Изменит ли как-то ситуацию удаление директории /var/lock/subsys из > initrd? > > Ещё одна версия, что какой-то демон чего-то успел записать в /var/lock, также > не нашла подтверждения у меня. В этом случае должны были остаться какие-то > следы от него, чего нет в /var/lock. > > Может добавим плюсик? Проблема с /var/run также решается добавлением плюсика в > /lib/tmpfiles.d/var.conf в строку: > L /var/run - - - - ../run Нет, плюсик использовать нельзя. Так же смотрите https://bugzilla.altlinux.org/show_bug.cgi?id=32358 Удивляет то, как вам удаётся получить разные /var/run и /run, /var/lock и /run/lock. Раньше они должны были бить одинаковы, потому что были соответствующие mount -o bind, сейчас это нужно добиться симлинком. Возможно кто-то успевает записать что-то в /var/run или в /var/lock до начала работы tmpfiles. Надо найти это место и научить писать в /run. 174732 12 zxwarior 2018-10-04 21:55:45 +0300 (В ответ на комментарий №0) > После последнего обновления filesystem в регулярках на sysV нет директории > /var/lock/subsys/ В результате многие службы жалуются, что не могут создать > lock файл в этой директории. Проблема вызвана вот этим коммитом ориентировочно: > http://git.altlinux.org/people/ldv/packages/?p=filesystem.git;a=commitdiff;h=ab242a12ddb4d29fbc6523d0bb5bdf584c31ef12 > > Я так понимаю, что директории должны создаваться в tmpfs, на на sysV создаётся > только /var/lock/ а директорий: > > %attr(0700,root,root) %dir /var/lock/subsys %ghost > %attr(0770,root,uucp) %dir /var/lock/uucp %ghost > %attr(0770,root,uucp) %dir /var/lock/serial %ghost > > нет. > > Проблема, как на _live_, так и установленной системе. Антон, всё гораздо хитрее и запутаннее :-) В squashfs: # ls -l /.ro/var/ | grep 'lock\|run' drwxr-xr-x 3 root root 46 окт 3 08:36 lock drwxr-xr-x 17 root root 250 окт 3 08:36 run # mount | grep '/\.ro' /dev/loop0 on /.ro type squashfs (ro,relatime) Помнишь ман про L,L+? А теперь ложка соли на этот торт: subsys создаётся только для /run/lock, но не для /var/lock: # grep . /lib/tmpfiles.d/* | grep 'subsys\|uucp\|serial' | grep -v \# /lib/tmpfiles.d/legacy.conf:d /run/lock/subsys 0700 root root - /lib/tmpfiles.d/legacy.conf:d /run/lock/serial 0770 root uucp - В результате сервисы sysv требующие /var/lock/subsys обламываются на загрузке sysv с огромной руганью. И если принудительно не линковать через L+, эта ругань в tty1 будет продолжаться бесконечно. Как вариант, можно в /lib/tmpfiles.d/legacy.conf прописать d /var/lock/subsys 0700 root root - Но содержимое каталогов будет разным: - Часть sysv сервисов создаёт lock-и в /var/lock/subsys, а другие в /run/lock/subsys И без линковки через L+, они будут разными. 174733 13 zxwarior 2018-10-04 22:11:08 +0300 (В ответ на комментарий №12) > > ... > > Как вариант, можно в > > /lib/tmpfiles.d/legacy.conf > > прописать > > d /var/lock/subsys 0700 root root - > > Но содержимое каталогов будет разным: > - Часть sysv сервисов создаёт lock-и в /var/lock/subsys, > а другие в /run/lock/subsys > И без линковки через L+, они будут разными. Но при этом нужно помнить, что systemd-tmpfiles работает подобно 'mkdir -p' и обрабатывает *.conf в лексикографическом порядке вне зависимости от того в каком каталоге */*tmpfiles.d они находятся. Это упоминает man tmpfiles.d 174805 14 7801 antohami 2018-10-08 14:37:41 +0300 Created attachment 7801 Исправление скрипта cleanup пакета startup Предлагаю решить проблему вот таким образом. Т.е. при каждом запуске дропать /var/run и /var/lock, если это не симлинки, после чего будет происходить успешное создание симлинков. Пришлось переместить создание tmpfiles вверх, так как иначе utmp писать некуда. Это принципиальной момент, что systemd-tmpfiles --remove --create --boot --exclude-prefix=/dev выполняется после? Я проверил, так работает. 174976 15 mike 2018-10-15 20:51:10 +0300 2 ldv@ и shaba@: коллеги, исправьте всё-таки сломанное в августе. У нас всё это время http://altlinux.org/rescue грузится так, что я бы сам испугался и поискал какой-нибудь менее сломанный на вид инструмент. 175037 16 shaba 2018-10-16 19:33:29 +0300 (В ответ на комментарий №15) > 2 ldv@ и shaba@: коллеги, исправьте всё-таки сломанное в августе. > > У нас всё это время http://altlinux.org/rescue грузится так, что я бы сам > испугался и поискал какой-нибудь менее сломанный на вид инструмент. В rescue свой rc.sysinit.rescue, который совсем не использует cleanup, и соответственно не запускает systemd-tmpfiles. Для rescue тебе надо где-то самостоятельно создать симлинки. 175465 17 shaba 2018-10-31 19:50:52 +0300 (В ответ на комментарий №14) > Created an attachment (id=7801) [details] > Исправление скрипта cleanup пакета startup > > Предлагаю решить проблему вот таким образом. > Т.е. при каждом запуске дропать /var/run и /var/lock, если это не симлинки, > после чего будет происходить успешное создание симлинков. Пришлось переместить > создание tmpfiles вверх, так как иначе utmp писать некуда. Это принципиальной > момент, что > > systemd-tmpfiles --remove --create --boot --exclude-prefix=/dev > > выполняется после? Я проверил, так работает. Это изменение в задании #215964 175467 18 antohami 2018-10-31 20:01:04 +0300 (В ответ на комментарий №17) > (В ответ на комментарий №14) > > Created an attachment (id=7801) [details] [details] > > Исправление скрипта cleanup пакета startup > > > > Предлагаю решить проблему вот таким образом. > > Т.е. при каждом запуске дропать /var/run и /var/lock, если это не симлинки, > > после чего будет происходить успешное создание симлинков. Пришлось переместить > > создание tmpfiles вверх, так как иначе utmp писать некуда. Это принципиальной > > момент, что > > > > systemd-tmpfiles --remove --create --boot --exclude-prefix=/dev > > > > выполняется после? Я проверил, так работает. > > Это изменение в задании #215964 Если сами директории /var/run и /var/lock не удалять, толку не будет же. Симлинки вместо них не создадутся, а потому нужные директории не появятся в них. 175468 19 shaba 2018-10-31 20:25:50 +0300 На существующих инсталяциях миграцию делать никто не планирует. А на вновь устанавливаемых системах инстолятор должен позаботиться об их отсутствии на установленной системе. 175469 20 zxwarior 2018-11-01 04:25:57 +0300 (В ответ на комментарий №18) > Если сами директории /var/run и /var/lock не удалять, толку не будет же. > Симлинки вместо них не создадутся, а потому нужные директории не появятся в > них. Антон, на миграции лайва xfce с systemd на sysv, всё ещё хуже: После миграции с перезагрузкой через SysRq (systemd же грохнули), /var/{lock,run}, /run/lock/{serial,subsys}, как были каталогами, так и остались каталогами, а вот /var/lock/{serial,subsys}, исчезли после перезагрузки. А кто их исчез,кто его знает. Они просто исчезли в /.rw/* https://forum.altlinux.org/index.php?topic=36177.msg331931#msg331931 Как себе представляю: Если каталог /var/lock не грохнуть, то и симлинк не создастся, и serial с subsys исчезнут. Логгирования не будет, а отследить это можно только через tty1 на загрузке. Смотрел это на сборке xfce от 24.10. 175470 21 antohami 2018-11-01 07:35:26 +0300 (В ответ на комментарий №19) > На существующих инсталяциях миграцию делать никто не планирует. > А на вновь устанавливаемых системах инстолятор должен позаботиться об их > отсутствии на установленной системе. Ок. Буду репу чесать в этом направлении. (В ответ на комментарий №20) > (В ответ на комментарий №18) > > Если сами директории /var/run и /var/lock не удалять, толку не будет же. > > Симлинки вместо них не создадутся, а потому нужные директории не появятся в > > них. > > Антон, на миграции лайва xfce с systemd на sysv, всё ещё хуже: > После миграции с перезагрузкой через SysRq (systemd же грохнули), > /var/{lock,run}, /run/lock/{serial,subsys}, как были каталогами, так и остались > каталогами, а вот /var/lock/{serial,subsys}, исчезли после перезагрузки. А кто > их исчез,кто его знает. Они просто исчезли в /.rw/* > https://forum.altlinux.org/index.php?topic=36177.msg331931#msg331931 > Как себе представляю: > Если каталог /var/lock не грохнуть, то и симлинк не создастся, и serial с > subsys исчезнут. Логгирования не будет, а отследить это можно только через tty1 > на загрузке. Смотрел это на сборке xfce от 24.10. Никаких чудес. /run/lock/{serial,subsys} создаются динамически в tmpfiles. systemd просто выдаёт предупреждение, что /var/lock это директория, а сам монтирует туда /run/lock. Директория /var/lock при этом жива и здорова, но без поддиректорий /var/lock/{serial,subsys}, так как они ни кем не созданы (их нет более в пакете filesystem). Их нужно либо создать, либо превратить в симлинк /var/lock 175501 22 antohami 2018-11-01 18:16:24 +0300 (В ответ на комментарий №17) > (В ответ на комментарий №14) > > Created an attachment (id=7801) [details] [details] > > Исправление скрипта cleanup пакета startup > > > > Предлагаю решить проблему вот таким образом. > > Т.е. при каждом запуске дропать /var/run и /var/lock, если это не симлинки, > > после чего будет происходить успешное создание симлинков. Пришлось переместить > > создание tmpfiles вверх, так как иначе utmp писать некуда. Это принципиальной > > момент, что > > > > systemd-tmpfiles --remove --create --boot --exclude-prefix=/dev > > > > выполняется после? Я проверил, так работает. > > Это изменение в задании #215964 Сборка regular-jeos с этим заданием не устанавливается. Жалуется на отсутствие пакета installer-feature-powerbutton-stage2. Где тут связь так сразу и не пойму... 175503 23 zxwarior 2018-11-01 18:40:13 +0300 (В ответ на комментарий №21) > Никаких чудес. /run/lock/{serial,subsys} создаются динамически в tmpfiles. > systemd просто выдаёт предупреждение, что /var/lock это директория, а сам > монтирует туда /run/lock. Директория /var/lock при этом жива и здорова, но без > поддиректорий /var/lock/{serial,subsys}, так как они ни кем не созданы (их нет > более в пакете filesystem). Их нужно либо создать, либо превратить в симлинк > /var/lock Спасибо Антон, вижу: var-lock.mount следует алгоритму Если /var/lock каталог, то bind-ить /run/lock в /var/run. Если /var/lock симлинк, то не биндить. А поскольку systemd при миграции на sysv выносится $ rpm -qf /lib/systemd/system/var-lock.mount systemd-239-alt3.i586 то ломается bind и /var/lock пустой. 175504 24 antohami 2018-11-01 18:50:56 +0300 (В ответ на комментарий №23) > (В ответ на комментарий №21) > > Никаких чудес. /run/lock/{serial,subsys} создаются динамически в tmpfiles. > > systemd просто выдаёт предупреждение, что /var/lock это директория, а сам > > монтирует туда /run/lock. Директория /var/lock при этом жива и здорова, но без > > поддиректорий /var/lock/{serial,subsys}, так как они ни кем не созданы (их нет > > более в пакете filesystem). Их нужно либо создать, либо превратить в симлинк > > /var/lock > > Спасибо Антон, вижу: > > var-lock.mount следует алгоритму > Если /var/lock каталог, то bind-ить /run/lock в /var/run. > Если /var/lock симлинк, то не биндить. > > А поскольку systemd при миграции на sysv выносится > $ rpm -qf /lib/systemd/system/var-lock.mount > systemd-239-alt3.i586 > > то ломается bind и /var/lock пустой. Alexey Shabalin, может перенести /lib/systemd/system/var-lock.mount в systemd-utils? 175505 25 antohami 2018-11-01 18:51:52 +0300 (В ответ на комментарий №22) > (В ответ на комментарий №17) > > (В ответ на комментарий №14) > > > Created an attachment (id=7801) [details] [details] [details] > > > Исправление скрипта cleanup пакета startup > > > > > > Предлагаю решить проблему вот таким образом. > > > Т.е. при каждом запуске дропать /var/run и /var/lock, если это не симлинки, > > > после чего будет происходить успешное создание симлинков. Пришлось переместить > > > создание tmpfiles вверх, так как иначе utmp писать некуда. Это принципиальной > > > момент, что > > > > > > systemd-tmpfiles --remove --create --boot --exclude-prefix=/dev > > > > > > выполняется после? Я проверил, так работает. > > > > Это изменение в задании #215964 > > Сборка regular-jeos с этим заданием не устанавливается. Жалуется на отсутствие > пакета installer-feature-powerbutton-stage2. Где тут связь так сразу и не > пойму... извиняюсь, installer-feature-powerbutton-stage3 175506 26 antohami 2018-11-01 18:56:59 +0300 (В ответ на комментарий №24) > (В ответ на комментарий №23) > > (В ответ на комментарий №21) > > > Никаких чудес. /run/lock/{serial,subsys} создаются динамически в tmpfiles. > > > systemd просто выдаёт предупреждение, что /var/lock это директория, а сам > > > монтирует туда /run/lock. Директория /var/lock при этом жива и здорова, но без > > > поддиректорий /var/lock/{serial,subsys}, так как они ни кем не созданы (их нет > > > более в пакете filesystem). Их нужно либо создать, либо превратить в симлинк > > > /var/lock > > > > Спасибо Антон, вижу: > > > > var-lock.mount следует алгоритму > > Если /var/lock каталог, то bind-ить /run/lock в /var/run. > > Если /var/lock симлинк, то не биндить. > > > > А поскольку systemd при миграции на sysv выносится > > $ rpm -qf /lib/systemd/system/var-lock.mount > > systemd-239-alt3.i586 > > > > то ломается bind и /var/lock пустой. > > Alexey Shabalin, может перенести /lib/systemd/system/var-lock.mount в > systemd-utils? Хотя оно же systemd вызывается. Я проверял, наличие пакета systemd в системе на sysV проблему не решает. 175508 27 zxwarior 2018-11-01 20:59:40 +0300 (В ответ на комментарий №26) > (В ответ на комментарий №24) > > (В ответ на комментарий №23) > > > (В ответ на комментарий №21) > > > > Никаких чудес. /run/lock/{serial,subsys} создаются динамически в tmpfiles. > > > > systemd просто выдаёт предупреждение, что /var/lock это директория, а сам > > > > монтирует туда /run/lock. Директория /var/lock при этом жива и здорова, но без > > > > поддиректорий /var/lock/{serial,subsys}, так как они ни кем не созданы (их нет > > > > более в пакете filesystem). Их нужно либо создать, либо превратить в симлинк > > > > /var/lock > > > > > > Спасибо Антон, вижу: > > > > > > var-lock.mount следует алгоритму > > > Если /var/lock каталог, то bind-ить /run/lock в /var/run. > > > Если /var/lock симлинк, то не биндить. > > > > > > А поскольку systemd при миграции на sysv выносится > > > $ rpm -qf /lib/systemd/system/var-lock.mount > > > systemd-239-alt3.i586 > > > > > > то ломается bind и /var/lock пустой. > > > > Alexey Shabalin, может перенести /lib/systemd/system/var-lock.mount в > > systemd-utils? > > Хотя оно же systemd вызывается. Я проверял, наличие пакета systemd в системе на > sysV проблему не решает. В systemd там хитро заморочено: L /var/lock - - - - ../run/lock в /lib/tmpfiles.d/legacy.conf отработает, если это новая инсталляция, где /var/lock, это призрак в filesystem. Но в regulsr-xfce не отработает, поскольку /var/lock, это каталог и он существует. /lib/systemd/system/var-lock.mount проверяет: Если /var/lock не симлинк, то биндить /run/lock в /var/lock. Как себе представляю в sysv: Где-то в rc.sysinit, до старта всех сервисов делать проверку скриптом: Если /var/lock не существует, то сделать симлинк /var/lock на /run/lock иначе если /var/lock это каталог и не bind, то удалить /var/lock и сделать симлинк /var/lock на /run/lock В devuan например, идёт проверка через файл функций mount-functions.sh на 676 строк. 175510 28 zxwarior 2018-11-02 03:59:12 +0300 (В ответ на комментарий №26) > (В ответ на комментарий №24) ... > > Alexey Shabalin, может перенести /lib/systemd/system/var-lock.mount в > > systemd-utils? > > Хотя оно же systemd вызывается. Я проверял, наличие пакета systemd в системе на > sysV проблему не решает. Более того, одна функция миграции /var/* на tmpfs, в systemd размазана по всей системе: /lib/systemd/system/var-lock.mount отвечающий за bind, привязан к systemd и без него работать не будет. а systemd-линковка через /lib/tmpfiles.d/*, привязана к системе в целом: # grep systemd-tmpfiles /etc/rc.d/scripts/cleanup systemd-tmpfiles --clean systemd-tmpfiles --remove --create --boot --exclude-prefix=/dev # grep -i cleanup /etc/rc.d/rc.sysinit # Cleanup everything :) action "Cleaning up temporary files from previous boot:" /etc/rc.d/scripts/cleanup и без этого пакета в sysv, линковка работать не будет: # rpm -qf /sbin/systemd-tmpfiles systemd-utils-239-alt3.i586 Но в целом, systemd следует алгоритму: - или bind или линк в зависимости от наличия или отсутствия /var/lock В лайве regular-xfce будет bind. 175537 29 antohami 2018-11-02 19:17:19 +0300 (В ответ на комментарий №22) > (В ответ на комментарий №17) > > (В ответ на комментарий №14) > > > Created an attachment (id=7801) [details] [details] [details] > > > Исправление скрипта cleanup пакета startup > > > > > > Предлагаю решить проблему вот таким образом. > > > Т.е. при каждом запуске дропать /var/run и /var/lock, если это не симлинки, > > > после чего будет происходить успешное создание симлинков. Пришлось переместить > > > создание tmpfiles вверх, так как иначе utmp писать некуда. Это принципиальной > > > момент, что > > > > > > systemd-tmpfiles --remove --create --boot --exclude-prefix=/dev > > > > > > выполняется после? Я проверил, так работает. > > > > Это изменение в задании #215964 > > Сборка regular-jeos с этим заданием не устанавливается. Жалуется на отсутствие > пакета installer-feature-powerbutton-stage2. Где тут связь так сразу и не > пойму... Проблема у моей локальной сборочницы. rpm пакеты вообще в образ перестали попадать. Собрал на сервере basalt, тяну себе, чтобы проверить сборку с заданием и сегодняшними правками m-p. 175550 30 antohami 2018-11-05 19:12:16 +0300 В задании 216049 подготовлены новые версии пакетов startup-rescue и installer. Изменения: 1. В startup-rescue и installer добавлено выполнение systemd-tmpfiles во время инициализации. Без этого миграция на симлинки невозможна. 2. В installer добавлен постинсталл скрипт, который: 2.1 создаёт симлинки /var/run -> ../run; /var/lock -> ../run/lock 2.2 Исправляет /var/run на /run в конфигах /{etc,lib}/tmpfiles.d/*.conf (Иначе получаем предупреждения, что конфиги устарели). Надо бы все эти конфиги исправить, а этот хак убрать. Также я думаю, что можно было бы убрать хак 2.1, если бы при первой установке пакета filesystem создавались симлинки: /var/run -> ../run; /var/lock -> ../run/lock При обновлениях скрипт отрабатывать не должен. Такое сделать же можно? Также подготовил коммит для m-p, который делает тоже, что и 2.1 с 2.2, но для live. Если сможем решить проблему через filesystem, то он будет также не нужен. Изменения m-p, а также задания 216049 и 215964 проверял на сборке образов: regular-{jeos, rescue, lxde, icewm} Ещё заметил, что при миграции на симлинки udev, который запускается до systemd-tmpfiles жалуется на отсутствие /var/lock/subsys/, а потому желательно, чтобы udev свой lock файл хранил в /run (речь об init-скрипте). 175551 31 ldv 2018-11-05 19:27:40 +0300 (In reply to comment #30) > Также я думаю, что можно было бы убрать хак 2.1, если бы при первой установке > пакета filesystem создавались симлинки: /var/run -> ../run; /var/lock -> > ../run/lock При обновлениях скрипт отрабатывать не должен. Такое сделать же > можно? Нет, нельзя, во время установки пакета filesystem ничего ещё нет. Вообще, поскольку объекты /var/run, /var/lock, и /var/lock/* в пакете filesystem указаны именно как каталоги, а не как симлинки, попытка превратить их в симлинки приведёт к неприятностям. 175649 32 7848 antohami 2018-11-08 18:10:45 +0300 Created attachment 7848 патч для m-p 175650 33 antohami 2018-11-08 18:13:12 +0300 (В ответ на комментарий №31) > (In reply to comment #30) > > Также я думаю, что можно было бы убрать хак 2.1, если бы при первой установке > > пакета filesystem создавались симлинки: /var/run -> ../run; /var/lock -> > > ../run/lock При обновлениях скрипт отрабатывать не должен. Такое сделать же > > можно? > > Нет, нельзя, во время установки пакета filesystem ничего ещё нет. В таком случае прошу высказать свои замечания по таску 216049 и черновому патчу к m-p. 177206 34 klark.devel 2019-01-09 18:36:57 +0300 (В ответ на комментарий №31) > (In reply to comment #30) > > Также я думаю, что можно было бы убрать хак 2.1, если бы при первой установке > > пакета filesystem создавались симлинки: /var/run -> ../run; /var/lock -> > > ../run/lock При обновлениях скрипт отрабатывать не должен. Такое сделать же > > можно? > > Нет, нельзя, во время установки пакета filesystem ничего ещё нет. Почему нельзя? С учётом того, что говорит rpm -qf и FHS 3.0 (#3.15) можно в том же filesystem сделать каталог /run/lock, принадлежащим этому же пакету, да и оба симлинка тоже. > Вообще, поскольку объекты /var/run, /var/lock, и /var/lock/* в пакете > filesystem указаны именно как каталоги, а не как симлинки, попытка превратить > их в симлинки приведёт к неприятностям. Тогда вопрос превращения в симлинки, наверное, решается при обновлении через %pre. Или наш rpm вообще на такое не рассчитан? 177212 35 klark.devel 2019-01-09 20:10:14 +0300 (В ответ на комментарий №34) > Тогда вопрос превращения в симлинки, наверное, решается при обновлении через > %pre. Или наш rpm вообще на такое не рассчитан? В общем случае силами RPM, скорее всего, не решается (в RedHat RPM 4.14.2 ситуация аналогична), но в конкретном случае через %pre решить можно по аналогии, как мне кажется: https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/ https://bugzilla.redhat.com/show_bug.cgi?id=447156 177213 36 mike 2019-01-09 20:12:12 +0300 %pre исполняется шеллом, его при установке filesystem может ещё и не быть. Попробуй проверить предложения практически, проверяя hsh --ini со своим репо. 179446 37 sem 2019-03-14 21:20:08 +0300 Эта проблема присутствует еще и в инсталляторе, там тоже нет каталогов в /var/lock. Сделаю объезд с удалением /var/lock и запуском systemd-tmpfiles. 179448 38 antohami 2019-03-15 06:02:47 +0300 (В ответ на комментарий №37) > Эта проблема присутствует еще и в инсталляторе, там тоже нет каталогов в > /var/lock. Сделаю объезд с удалением /var/lock и запуском systemd-tmpfiles. На прошлой неделе сделал объезд наоборот с созданием ghost директорий: git.altlinux.org/people/antohami/packages/mkimage-profiles.git commit 147964b05f50281fc2c2f4c278275638e4548531 Добавляется пакет installer-feature-create-ghost-directories Проблему в инсталлируемых регулярках решило. 179490 39 sem 2019-03-15 19:33:13 +0300 Я думаю это лучше делать в самом инсталляторе, т.к. нужно для всех дистрибутивов без исключения. 179491 40 antohami 2019-03-15 19:39:24 +0300 (В ответ на комментарий №39) > Я думаю это лучше делать в самом инсталляторе, т.к. нужно для всех > дистрибутивов без исключения. Я для всех и добавил в m-p этот пакет. Во все сборки, которые используют use/install2, попадёт пакет installer-feature-create-ghost-directories 179510 41 mike 2019-03-16 21:27:29 +0300 (В ответ на комментарий №40) > > Я думаю это лучше делать в самом инсталляторе, т.к. нужно для всех > > дистрибутивов без исключения. > Я для всех и добавил в m-p этот пакет. Во все сборки, которые используют > use/install2, попадёт пакет installer-feature-create-ghost-directories Миша явно про пакет installer. 179772 42 sem 2019-03-22 20:12:14 +0300 (В ответ на комментарий №41) > > Я для всех и добавил в m-p этот пакет. Во все сборки, которые используют > > use/install2, попадёт пакет installer-feature-create-ghost-directories В инталлер-фичах создавать поздно, udevd стартует раньше. > Миша явно про пакет installer. У меня в гите фиксы, но я пока не собираю, может еще что найдется исправить. 180770 43 antohami 2019-04-12 12:58:01 +0300 На заметку. При переходе на симлинки /var/run -> ../run и /var/lock -> ../run/lock NetworkManager не может подхватить управление интерфейсом eth0 (пишет, что устройство не управляется). Помогает перезапуск NetworkManager. 180772 44 antohami 2019-04-12 13:05:38 +0300 (В ответ на комментарий №43) > На заметку. При переходе на симлинки /var/run -> ../run и /var/lock -> > ../run/lock NetworkManager не может подхватить управление интерфейсом eth0 > (пишет, что устройство не управляется). Помогает перезапуск NetworkManager. На sysvinit 181745 45 shaba 2019-05-21 22:11:06 +0300 (В ответ на комментарий №28) > В лайве regular-xfce будет bind. Но зачем? Специально делаем что бы можно было перейти на симлинки и не мучаться больше с mount. А у вас опять двадцатьпять. 184070 46 antohami 2019-09-02 19:42:07 +0300 Мне пришла в голову идея создавать симлинки при установке пакета systemd-utils. Сделал это в задании #236987 EPERM #1 [test-only] sisyphus systemd.git=242-alt12 Сборка образов и rootfs проходит успешно. Но есть проблемы на sysVinit: (В ответ на комментарий №43) > На заметку. При переходе на симлинки /var/run -> ../run и /var/lock -> > ../run/lock NetworkManager не может подхватить управление интерфейсом eth0 > (пишет, что устройство не управляется). Помогает перезапуск NetworkManager. В ЦУС значится, что интерфейс не управляется. Если бы не эта проблема, я был бы за этот вариант, так как делать симлинки при сборке live не так просто. Если я просто удаляю директории /var/run и /var/lock, создаю симлинки, то при установке получаю ошибку от инсталлятора на этапе установки загрузчика: не найдены канонические пути overlayfs. Помогает копирование содержимого /var/run и /var/lock в /run и /run/lock соответсвенно. 184071 47 antohami 2019-09-02 19:43:27 +0300 >Мне пришла в голову идея создавать симлинки при установке пакета systemd-utils. При установке пакета в первый раз. 186331 48 antohami 2019-12-16 04:57:34 +0300 Проблема решается при сборке (rootfs, live) или установке (классический инсталятор) дистрибутивов. 7801 2018-10-08 14:37:41 +0300 2018-10-08 14:37:41 +0300 Исправление скрипта cleanup пакета startup fix_cleanup.patch text/plain 1025 antohami ZGlmZiAtLWdpdCBhL3N0YXJ0dXAvcmMuZC9zY3JpcHRzL2NsZWFudXAgYi9zdGFydHVwL3JjLmQv c2NyaXB0cy9jbGVhbnVwCmluZGV4IDcyMTQyZDEuLmE4MDY5ZGYgMTAwNzU1Ci0tLSBhL3N0YXJ0 dXAvcmMuZC9zY3JpcHRzL2NsZWFudXAKKysrIGIvc3RhcnR1cC9yYy5kL3NjcmlwdHMvY2xlYW51 cApAQCAtMTQsNyArMTQsOSBAQCBTb3VyY2VJZk5vdEVtcHR5IC9ldGMvc3lzY29uZmlnL3N5c3Rl bQogcm0gLWYgL2Zhc3Rib290IC9mc2Nrb3B0aW9ucyAvZm9yY2Vmc2NrIC9oYWx0IC9wb3dlcm9m ZgogCiAjIENsZWFuIHVwIC92YXIKLWZpbmQgL3Zhci9ydW4vIC92YXIvbG9jay8gLXR5cGUgZiAt ZGVsZXRlCitmaW5kIC9ydW4vIC9ydW4vbG9jay8gLXR5cGUgZiAtZGVsZXRlCit0ZXN0ICEgLUwg L3Zhci9ydW4vICYmIHJtIC1mciAvdmFyL3J1bgordGVzdCAhIC1MIC92YXIvbG9jay8gJiYgcm0g LWZyIC92YXIvbG9jawogCiBybSAtcmYgL3RtcC8uWCotbG9jayAvdG1wLy5JQ0UtdW5peCAvdG1w Ly5YMTEtdW5peCAvdG1wLy5lc2QgL3RtcC8uZm9udC11bml4CiBybSAtZiAvdG1wL2VzcnYqCkBA IC00Myw2ICs0NSw3IEBAIGlmIFsgLW4gIiRDTEVBTl9UTVAiIF0gJiYgWyAiJENMRUFOX1RNUCIg LWdlIDEgXTsgdGhlbgogZmkKIAogc3lzdGVtZC10bXBmaWxlcyAtLWNsZWFuCitzeXN0ZW1kLXRt cGZpbGVzIC0tcmVtb3ZlIC0tY3JlYXRlIC0tYm9vdCAtLWV4Y2x1ZGUtcHJlZml4PS9kZXYKIAog IyBQb3NzaWJseSBjcmVhdGUgbGFzdGxvZywgZmFpbGxvZywgdXRtcCBhbmQgd3RtcCwgcmVzZXQg dXRtcCBhbmQgcG9zc2libHkgdXRtcHguCiBmb3IgZiBpbiAvdmFyL2xvZy97bGFzdGxvZyxmYWls bG9nfTsgZG8KQEAgLTU5LDYgKzYyLDQgQEAgZG9uZQogPiAvdmFyL3J1bi91dG1wCiB0ZXN0IC1m IC92YXIvcnVuL3V0bXB4ICYmID4gL3Zhci9ydW4vdXRtcHgKIAotc3lzdGVtZC10bXBmaWxlcyAt LXJlbW92ZSAtLWNyZWF0ZSAtLWJvb3QgLS1leGNsdWRlLXByZWZpeD0vZGV2Ci0KIGV4aXQgMAo= 7848 2018-11-08 18:10:45 +0300 2018-11-08 18:10:45 +0300 патч для m-p 0001-migration-to-symlink-var-run-.-run-var-lock-.-run-lo.patch text/plain 2737 antohami RnJvbSA5MjJkMmY1NDdhMWRmNGU4NmQ3MjNlNzJjYjBlYzFkNWNmYzhlZWNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBbnRvbiBNaWR5dWtvdiA8YW50b2hhbWlAYWx0bGludXgub3Jn PgpEYXRlOiBNb24sIDUgTm92IDIwMTggMTk6NTc6MzUgKzA3MDAKU3ViamVjdDogW1BBVENIIDEv Ml0gbWlncmF0aW9uIHRvIHN5bWxpbms6IC92YXIvcnVuIC0+IC4uL3J1bjsgL3Zhci9sb2NrIC0+ CiAuLi9ydW4vbG9jawoKc2VlIGFsdCBidWcgMzUzNTAKLS0tCiAuLi4vaW5pdC9yZXNjdWUvaW1h Z2Utc2NyaXB0cy5kLzUwLXN5c3Zpbml0ICAgICAgfCAxNiAtLS0tLS0tLS0tLS0tLS0tCiAuLi4v aW5pdC9yb290ZnMvaW1hZ2Utc2NyaXB0cy5kLzUwLXN5c3Zpbml0ICAgICAgfCAxMiAtLS0tLS0t LS0tLS0KIC4uLi9zdGFnZTIvaW1hZ2Utc2NyaXB0cy5kLzk5LW1pZ3JhdGUtdG8tc3ltbGluayB8 IDEwICsrKysrKysrKysKIDMgZmlsZXMgY2hhbmdlZCwgMTAgaW5zZXJ0aW9ucygrKSwgMjggZGVs ZXRpb25zKC0pCiBkZWxldGUgbW9kZSAxMDA3NTUgZmVhdHVyZXMuaW4vaW5pdC9yZXNjdWUvaW1h Z2Utc2NyaXB0cy5kLzUwLXN5c3Zpbml0CiBjcmVhdGUgbW9kZSAxMDA3NTUgc3ViLmluL3N0YWdl Mi9pbWFnZS1zY3JpcHRzLmQvOTktbWlncmF0ZS10by1zeW1saW5rCgpkaWZmIC0tZ2l0IGEvZmVh dHVyZXMuaW4vaW5pdC9yZXNjdWUvaW1hZ2Utc2NyaXB0cy5kLzUwLXN5c3Zpbml0IGIvZmVhdHVy ZXMuaW4vaW5pdC9yZXNjdWUvaW1hZ2Utc2NyaXB0cy5kLzUwLXN5c3Zpbml0CmRlbGV0ZWQgZmls ZSBtb2RlIDEwMDc1NQppbmRleCA2YmU0YzNiZC4uMDAwMDAwMDAKLS0tIGEvZmVhdHVyZXMuaW4v aW5pdC9yZXNjdWUvaW1hZ2Utc2NyaXB0cy5kLzUwLXN5c3Zpbml0CisrKyAvZGV2L251bGwKQEAg LTEsMTYgKzAsMCBAQAotIyEvYmluL3NoCi0KLSMgdGhlIHBhcnQgYmVsb3cgcmVsYXRlcyB0byBz eXN2aW5pdCBzcGVjaWZpY2FsbHkKLXJwbSAtcSBzeXN2aW5pdCB8fCBleGl0IDAKLQotIyB0aGlz IHdhcyBhIGJ1bmNoIG9mIGRpcnR5IGNvbXBsYWludHMKLXNlZCAtaSAncywvdmFyL3J1biwvcnVu LCcgL3tldGMsbGlifS90bXBmaWxlcy5kLyouY29uZiB8fDoKLQotIyBodHRwczovL2J1Z3ppbGxh LmFsdGxpbnV4Lm9yZy8zNTM1MAotIyB0aGlzIEZBSUxTOiBubyBzeW1saW5rcy4uLgotI3JtIC1y ZiAvdmFyL3J1biAvdmFyL2xvY2sKLSMgLi4uc28ganVzdCByZXZlcnQgd2hhdCdzIGJlZW4gYnJv a2VuIGluIGZhaWxzeXN0ZW0gcGFja2FnZQotbWtkaXIgLXAgL3Zhci9ydW4gL3Zhci9sb2NrL3tz ZXJpYWwsc3Vic3lzLHV1Y3B9Ci1jaG1vZCAwNzcwIC92YXIvbG9jay9zdWJzeXMKLWNobW9kIDA3 NzAgL3Zhci9sb2NrL3tzZXJpYWwsdXVjcH0KLWNoZ3JwIHV1Y3AgL3Zhci9sb2NrL3tzZXJpYWws dXVjcH0KZGlmZiAtLWdpdCBhL2ZlYXR1cmVzLmluL2luaXQvcm9vdGZzL2ltYWdlLXNjcmlwdHMu ZC81MC1zeXN2aW5pdCBiL2ZlYXR1cmVzLmluL2luaXQvcm9vdGZzL2ltYWdlLXNjcmlwdHMuZC81 MC1zeXN2aW5pdAppbmRleCAzOTBkNDkwZi4uNDBhZWI2OGIgMTAwNzU1Ci0tLSBhL2ZlYXR1cmVz LmluL2luaXQvcm9vdGZzL2ltYWdlLXNjcmlwdHMuZC81MC1zeXN2aW5pdAorKysgYi9mZWF0dXJl cy5pbi9pbml0L3Jvb3Rmcy9pbWFnZS1zY3JpcHRzLmQvNTAtc3lzdmluaXQKQEAgLTgsMTUgKzgs MyBAQCBycG0gLXEgc3lzdmluaXQgfHwgZXhpdCAwCiBjYXNlICIkR0xPQkFMX0dST1VQUyIgaW4K IAkqX25tY29ubmVjdCopIGdyb3VwYWRkIC1yIF9ubWNvbm5lY3QgfHw6OzsKIGVzYWMKLQotIyB0 aGlzIHdhcyBhIGJ1bmNoIG9mIGRpcnR5IGNvbXBsYWludHMKLXNlZCAtaSAncywvdmFyL3J1biwv cnVuLCcgL3tldGMsbGlifS90bXBmaWxlcy5kLyouY29uZiB8fDoKLQotIyBodHRwczovL2J1Z3pp bGxhLmFsdGxpbnV4Lm9yZy8zNTM1MAotIyB0aGlzIEZBSUxTOiBubyBzeW1saW5rcy4uLgotI3Jt IC1yZiAvdmFyL3J1biAvdmFyL2xvY2sKLSMgLi4uc28ganVzdCByZXZlcnQgd2hhdCdzIGJlZW4g YnJva2VuIGluIGZhaWxzeXN0ZW0gcGFja2FnZQotbWtkaXIgLXAgL3Zhci9ydW4gL3Zhci9sb2Nr L3tzZXJpYWwsc3Vic3lzLHV1Y3B9Ci1jaG1vZCAwNzcwIC92YXIvbG9jay9zdWJzeXMKLWNobW9k IDA3NzAgL3Zhci9sb2NrL3tzZXJpYWwsdXVjcH0KLWNoZ3JwIHV1Y3AgL3Zhci9sb2NrL3tzZXJp YWwsdXVjcH0KZGlmZiAtLWdpdCBhL3N1Yi5pbi9zdGFnZTIvaW1hZ2Utc2NyaXB0cy5kLzk5LW1p Z3JhdGUtdG8tc3ltbGluayBiL3N1Yi5pbi9zdGFnZTIvaW1hZ2Utc2NyaXB0cy5kLzk5LW1pZ3Jh dGUtdG8tc3ltbGluawpuZXcgZmlsZSBtb2RlIDEwMDc1NQppbmRleCAwMDAwMDAwMC4uNmQ0NjM4 ZDcKLS0tIC9kZXYvbnVsbAorKysgYi9zdWIuaW4vc3RhZ2UyL2ltYWdlLXNjcmlwdHMuZC85OS1t aWdyYXRlLXRvLXN5bWxpbmsKQEAgLTAsMCArMSwxMCBAQAorIyEvYmluL3NoCisKK2NwIC1hIC92 YXIvcnVuLyogL3J1bi8KK2NwIC1hIC92YXIvbG9jay8gL3J1bi8KK3JtIC1mciAvdmFyL3tydW4s bG9ja30KK2xuIC1zIC4uL3J1biAvdmFyL3J1bgorbG4gLXMgLi4vcnVuL2xvY2sgL3Zhci9sb2Nr CisKKyMgdGhpcyB3YXMgYSBidW5jaCBvZiBkaXJ0eSBjb21wbGFpbnRzCitzZWQgLWkgJ3MsL3Zh ci9ydW4sL3J1biwnIC97ZXRjLGxpYn0vdG1wZmlsZXMuZC8qLmNvbmYgfHw6Ci0tIAoyLjE3LjIK Cg==