Bug 35350

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

Хотелось бы понять, почему у вас не отрабатывает 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) или установке (классический инсталятор) дистрибутивов.