После последнего обновления 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, так и установленной системе.
...и это ещё одна проблема, которую можно было поймать на тестовых регулярках, а не разломав мне сизиф в самый неудобный для того по нагрузке момент. Просьба в будущем не стесняться запросить сборку/проверку.
Хотелось бы понять, почему у вас не отрабатывает tmpfiles? В конфиге /lib/tmpfiles.d/legacy.conf присутствует: d /run/lock/subsys 0700 root root - Точнее, хотелось бы понять, почему у вас /run не тоже самое что и /var/run
извиняюсь, почему /var/lock не тоже самое что /run/lock
(В ответ на комментарий №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.
(В ответ на комментарий №4) > Какой пакет отвечает за отработку правил /lib/tmpfiles.d/ ? systemd-tmpfiles из пакета systemd-utils. Для sysV нужен инит-скрипт для него.
(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.
(В ответ на комментарий №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? Или не тогда, когда надо?
(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? Или не тогда, когда надо?
Причина нашлась: 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
(В ответ на комментарий №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-файла.
(В ответ на комментарий №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.
(В ответ на комментарий №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+, они будут разными.
(В ответ на комментарий №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
Created attachment 7801 [details] Исправление скрипта cleanup пакета startup Предлагаю решить проблему вот таким образом. Т.е. при каждом запуске дропать /var/run и /var/lock, если это не симлинки, после чего будет происходить успешное создание симлинков. Пришлось переместить создание tmpfiles вверх, так как иначе utmp писать некуда. Это принципиальной момент, что systemd-tmpfiles --remove --create --boot --exclude-prefix=/dev выполняется после? Я проверил, так работает.
2 ldv@ и shaba@: коллеги, исправьте всё-таки сломанное в августе. У нас всё это время http://altlinux.org/rescue грузится так, что я бы сам испугался и поискал какой-нибудь менее сломанный на вид инструмент.
(В ответ на комментарий №15) > 2 ldv@ и shaba@: коллеги, исправьте всё-таки сломанное в августе. > > У нас всё это время http://altlinux.org/rescue грузится так, что я бы сам > испугался и поискал какой-нибудь менее сломанный на вид инструмент. В rescue свой rc.sysinit.rescue, который совсем не использует cleanup, и соответственно не запускает systemd-tmpfiles. Для rescue тебе надо где-то самостоятельно создать симлинки.
(В ответ на комментарий №14) > Created an attachment (id=7801) [details] > Исправление скрипта cleanup пакета startup > > Предлагаю решить проблему вот таким образом. > Т.е. при каждом запуске дропать /var/run и /var/lock, если это не симлинки, > после чего будет происходить успешное создание симлинков. Пришлось переместить > создание tmpfiles вверх, так как иначе utmp писать некуда. Это принципиальной > момент, что > > systemd-tmpfiles --remove --create --boot --exclude-prefix=/dev > > выполняется после? Я проверил, так работает. Это изменение в задании #215964
(В ответ на комментарий №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 не удалять, толку не будет же. Симлинки вместо них не создадутся, а потому нужные директории не появятся в них.
На существующих инсталяциях миграцию делать никто не планирует. А на вновь устанавливаемых системах инстолятор должен позаботиться об их отсутствии на установленной системе.
(В ответ на комментарий №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.
(В ответ на комментарий №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
(В ответ на комментарий №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. Где тут связь так сразу и не пойму...
(В ответ на комментарий №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 пустой.
(В ответ на комментарий №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?
(В ответ на комментарий №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
(В ответ на комментарий №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 проблему не решает.
(В ответ на комментарий №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 строк.
(В ответ на комментарий №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.
(В ответ на комментарий №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.
В задании 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-скрипте).
(In reply to comment #30) > Также я думаю, что можно было бы убрать хак 2.1, если бы при первой установке > пакета filesystem создавались симлинки: /var/run -> ../run; /var/lock -> > ../run/lock При обновлениях скрипт отрабатывать не должен. Такое сделать же > можно? Нет, нельзя, во время установки пакета filesystem ничего ещё нет. Вообще, поскольку объекты /var/run, /var/lock, и /var/lock/* в пакете filesystem указаны именно как каталоги, а не как симлинки, попытка превратить их в симлинки приведёт к неприятностям.
Created attachment 7848 [details] патч для m-p
(В ответ на комментарий №31) > (In reply to comment #30) > > Также я думаю, что можно было бы убрать хак 2.1, если бы при первой установке > > пакета filesystem создавались симлинки: /var/run -> ../run; /var/lock -> > > ../run/lock При обновлениях скрипт отрабатывать не должен. Такое сделать же > > можно? > > Нет, нельзя, во время установки пакета filesystem ничего ещё нет. В таком случае прошу высказать свои замечания по таску 216049 и черновому патчу к m-p.
(В ответ на комментарий №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 вообще на такое не рассчитан?
(В ответ на комментарий №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
%pre исполняется шеллом, его при установке filesystem может ещё и не быть. Попробуй проверить предложения практически, проверяя hsh --ini со своим репо.
Эта проблема присутствует еще и в инсталляторе, там тоже нет каталогов в /var/lock. Сделаю объезд с удалением /var/lock и запуском systemd-tmpfiles.
(В ответ на комментарий №37) > Эта проблема присутствует еще и в инсталляторе, там тоже нет каталогов в > /var/lock. Сделаю объезд с удалением /var/lock и запуском systemd-tmpfiles. На прошлой неделе сделал объезд наоборот с созданием ghost директорий: git.altlinux.org/people/antohami/packages/mkimage-profiles.git commit 147964b05f50281fc2c2f4c278275638e4548531 Добавляется пакет installer-feature-create-ghost-directories Проблему в инсталлируемых регулярках решило.
Я думаю это лучше делать в самом инсталляторе, т.к. нужно для всех дистрибутивов без исключения.
(В ответ на комментарий №39) > Я думаю это лучше делать в самом инсталляторе, т.к. нужно для всех > дистрибутивов без исключения. Я для всех и добавил в m-p этот пакет. Во все сборки, которые используют use/install2, попадёт пакет installer-feature-create-ghost-directories
(В ответ на комментарий №40) > > Я думаю это лучше делать в самом инсталляторе, т.к. нужно для всех > > дистрибутивов без исключения. > Я для всех и добавил в m-p этот пакет. Во все сборки, которые используют > use/install2, попадёт пакет installer-feature-create-ghost-directories Миша явно про пакет installer.
(В ответ на комментарий №41) > > Я для всех и добавил в m-p этот пакет. Во все сборки, которые используют > > use/install2, попадёт пакет installer-feature-create-ghost-directories В инталлер-фичах создавать поздно, udevd стартует раньше. > Миша явно про пакет installer. У меня в гите фиксы, но я пока не собираю, может еще что найдется исправить.
На заметку. При переходе на симлинки /var/run -> ../run и /var/lock -> ../run/lock NetworkManager не может подхватить управление интерфейсом eth0 (пишет, что устройство не управляется). Помогает перезапуск NetworkManager.
(В ответ на комментарий №43) > На заметку. При переходе на симлинки /var/run -> ../run и /var/lock -> > ../run/lock NetworkManager не может подхватить управление интерфейсом eth0 > (пишет, что устройство не управляется). Помогает перезапуск NetworkManager. На sysvinit
(В ответ на комментарий №28) > В лайве regular-xfce будет bind. Но зачем? Специально делаем что бы можно было перейти на симлинки и не мучаться больше с mount. А у вас опять двадцатьпять.
Мне пришла в голову идея создавать симлинки при установке пакета 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 соответсвенно.
>Мне пришла в голову идея создавать симлинки при установке пакета systemd-utils. При установке пакета в первый раз.
Проблема решается при сборке (rootfs, live) или установке (классический инсталятор) дистрибутивов.
