Очистка текущим udev (201-alt1.M70P.5) каталога /run (и /var/run, если он связан с /run через симлинк или монтирование) вызывает проблемы, т. к. не все сервисы обучены воссоздать требуемые им каталоги в {,/var}/run. В systemd данную проблему решают конфиги в {/lib,/ect}/tmpfiles.d и обрабатывающий их systemd-tmpfiles. Но под sysvinit использовать systemd-tmpfiles затруднительно: 1. Сейчас systemd-tmpfiles входит в состав пакета systemd, и без systemd его не поставить. 2. Нет init скрипта для systemd-tmpfiles. Предлагаю: 1. Выделить systemd-tmpfiles из systemd в отдельный подпакет. 2. В выделенный подпакет добавить init скрипта для systemd-tmpfiles. В результате, если systemd-tmpfiles способен работать не в среде systemd, получим типовое решение для воссоздания структуры {,/var}/run независимо от используемой системы инициализации.
На Sisyphus.
- systemd-tmpfiles и так выделен в отдельный пакет systemd-utils. - для создания static-nodes в /dev используется systemd-tmpfiles под sysv из /etc/rc.d/init.d/udevd - для очистки временных файлов тоже используется systemd-tmpfiles --clean в /etc/rc.d/scripts/cleanup Делать init скрипт для systemd-tmpfiles мне кажется опасным. Либо надо делать так, что он отработает только при загрузке, и нельзя его будет запускать повторно. В общем куда его вставить правильнее, я не знаю.
(В ответ на комментарий №2) > - systemd-tmpfiles и так выделен в отдельный пакет systemd-utils. На Сизифе -- да (начиная с systemd-203-alt1). Но в p7, на который данная бага вешались -- systemd-201-alt1.M70P.5, в котором подпакет systemd-utils из пакета systemd не выделен. > - для создания static-nodes в /dev используется systemd-tmpfiles под sysv из > /etc/rc.d/init.d/udevd > - для очистки временных файлов тоже используется systemd-tmpfiles --clean в > /etc/rc.d/scripts/cleanup В первом приближении, для /dev, описанного достаточно. Но надо сделать что-то подобное не только для /dev. > > Делать init скрипт для systemd-tmpfiles мне кажется опасным. Либо надо делать > так, что он отработает только при загрузке, и нельзя его будет запускать > повторно. Не вижу необходимости избежания повторного запуска: 1. Экспресс тестирование последовательного systemd-tmpfiles --create на загруженной системе каких либо проблем не показало. 2. Повторный systemd-tmpfiles --create --remove к проблемам тоже приводить недолжен, т. к. при использовании systemd таймер systemd-tmpfiles-clean.timer активируется по умолчанию. А он вызывает ежедневный запуск systemd-tmpfiles-clean.service, выполняющий означенную команду. > В общем куда его вставить правильнее, я не знаю. У меня пока вырисовывается следующая схема: 1. Нужно использовать некий флаг, что запущен /etc/init.d/tmpfiles. Например пустой файл /var/lock/subsys/tmpfiles. 2. Нужно иметь /etc/init.d/tmpfiles, умеющий стандартный набор команд {start|stop|reload|restart|condstop|condrestart|condreload|status}, расширенный командами {clean|condclean}. 3. Скрипт /etc/cron.daily/tmpfiles, раз в сутки вызывающий /etc/init.d/tmpfiles condclean. По моему так функционал systemd-tmpfiles под sysvinit будет соответствовать большей части его же функционала под systemd. (За бортом осталась только очистка каталогов через 15 мин. после старта. Что не критично на мой взгляд.) Непонятно только как исключить конфликт с unit`ами systemd-tmpfiles-{start,clean}.service, при работе под systemd... Вынести всё это в пакет systemd-tmpfiles-sysvinit, зависящий от sysvinit?
(В ответ на комментарий №3) > (В ответ на комментарий №2) > > - systemd-tmpfiles и так выделен в отдельный пакет systemd-utils. > > На Сизифе -- да (начиная с systemd-203-alt1). Но в p7, на который данная бага > вешались -- systemd-201-alt1.M70P.5, в котором подпакет systemd-utils из пакета > systemd не выделен. Под p7 я делать ничего не буду. Для p7 у меня давным-давно есть сборка версии 208, которую не пропускают.
(В ответ на комментарий №4) > (В ответ на комментарий №3) > > (В ответ на комментарий №2) > > > - systemd-tmpfiles и так выделен в отдельный пакет systemd-utils. > > > > На Сизифе -- да (начиная с systemd-203-alt1). Но в p7, на который данная бага > > вешались -- systemd-201-alt1.M70P.5, в котором подпакет systemd-utils из пакета > > systemd не выделен. > > Под p7 я делать ничего не буду. Для p7 у меня давным-давно есть сборка версии > 208, которую не пропускают. Я могу спортировать выделение systemd-utils и поддержку tmpfiles для sysvinit (сейчас делаю) на текущие варианты пакетов p7/t7 (201-alt1.M70P.5/201-alt1.M70T.2).
(В ответ на комментарий №5) > (В ответ на комментарий №4) > > (В ответ на комментарий №3) > > > (В ответ на комментарий №2) > > > > - systemd-tmpfiles и так выделен в отдельный пакет systemd-utils. > > > > > > На Сизифе -- да (начиная с systemd-203-alt1). Но в p7, на который данная бага > > > вешались -- systemd-201-alt1.M70P.5, в котором подпакет systemd-utils из пакета > > > systemd не выделен. > > > > Под p7 я делать ничего не буду. Для p7 у меня давным-давно есть сборка версии > > 208, которую не пропускают. > > Я могу спортировать выделение systemd-utils и поддержку tmpfiles для sysvinit > (сейчас делаю) на текущие варианты пакетов p7/t7 > (201-alt1.M70P.5/201-alt1.M70T.2). p7 уже не нужно трогать. Я всё равно не пропущу никаких изменений в systemd там.
(В ответ на комментарий №6) > (В ответ на комментарий №5) ... > > > > Я могу спортировать выделение systemd-utils и поддержку tmpfiles для sysvinit > > (сейчас делаю) на текущие варианты пакетов p7/t7 > > (201-alt1.M70P.5/201-alt1.M70T.2). > p7 уже не нужно трогать. Я всё равно не пропущу никаких изменений в systemd > там. А в t7 подобные изменения отправить можно?
(В ответ на комментарий №7) > (В ответ на комментарий №6) > > (В ответ на комментарий №5) > ... > > > > > > Я могу спортировать выделение systemd-utils и поддержку tmpfiles для sysvinit > > > (сейчас делаю) на текущие варианты пакетов p7/t7 > > > (201-alt1.M70P.5/201-alt1.M70T.2). > > p7 уже не нужно трогать. Я всё равно не пропущу никаких изменений в systemd > > там. > > А в t7 подобные изменения отправить можно? Если будете делать для t7, то сразу делайте на базе версии 208(у меня в репо есть бранч).
(В ответ на комментарий №8) ... > Если будете делать для t7, то сразу делайте на базе версии 208(у меня в репо > есть бранч). За основу брать 208-alt0.M70T.5 (см. <http://git.altlinux.org/people/shaba/packages/?p=systemd.git;a=tag;h=refs/tags/208-alt0.M70T.5>) или лучше 208-alt0.M70P.7 (см. <http://git.altlinux.org/people/shaba/packages/?p=systemd.git;a=tag;h=refs/tags/208-alt0.M70P.7>)? Я пока не понял что из них более похоже (по функционалу) на текущий 201-alt1.M70T.2 (см. <http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=tag;h=refs/tags/201-alt1.M70T.2>).
(В ответ на комментарий №9) > (В ответ на комментарий №8) > ... > > Если будете делать для t7, то сразу делайте на базе версии 208(у меня в репо > > есть бранч). > > За основу брать 208-alt0.M70T.5 (см. > <http://git.altlinux.org/people/shaba/packages/?p=systemd.git;a=tag;h=refs/tags/208-alt0.M70T.5>) > или лучше 208-alt0.M70P.7 (см. > <http://git.altlinux.org/people/shaba/packages/?p=systemd.git;a=tag;h=refs/tags/208-alt0.M70P.7>)? > Я пока не понял что из них более похоже (по функционалу) на текущий > 201-alt1.M70T.2 (см. > <http://git.altlinux.org/gears/s/systemd.git?p=systemd.git;a=tag;h=refs/tags/201-alt1.M70T.2>). 208-alt0.M70P.7 из p7/master
(В ответ на комментарий №3) ... > > У меня пока вырисовывается следующая схема: 228-alt2.1 (см. http://git.altlinux.org/people/solo/packages/?p=systemd.git;a=commit;h=7e9b0d90fd45b5ee9b94c63f8453b8970c9623cf) -- тестовая реализация для Сизифа. Тестовая сборка в http://git.altlinux.org/tasks/156192/ (но протестировать по факту, я смогу только вариант для t7). Особенности: > > 1. Нужно использовать некий флаг, что запущен /etc/init.d/tmpfiles. Например > пустой файл /var/lock/subsys/tmpfiles. > > 2. Нужно иметь /etc/init.d/tmpfiles, умеющий стандартный набор команд > {start|stop|reload|restart|condstop|condrestart|condreload|status}, расширенный > командами {clean|condclean}. /etc/init.d/tmpfiles обучен {start|stop|status|restart|condrestart|condstop|clean|condclean}. > > 3. Скрипт /etc/cron.daily/tmpfiles, раз в сутки вызывающий /etc/init.d/tmpfiles > condclean. > ... > Непонятно только как исключить конфликт с unit`ами > systemd-tmpfiles-{start,clean}.service, при работе под systemd... Вынести всё > это в пакет systemd-tmpfiles-sysvinit, зависящий от sysvinit? Всё сделанное вынесено в подпакет sysvinit-tmpfiles, конфликтующий с systemd-sysvinit (защита от выполнения /etc/init.d/tmpfiles под systemd). (В ответ на комментарий №10) > (В ответ на комментарий №9) > > (В ответ на комментарий №8) > > ... > > > Если будете делать для t7, то сразу делайте на базе версии 208(у меня в репо > > > есть бранч). > > > > За основу брать 208-alt0.M70T.5 (см. > > <http://git.altlinux.org/people/shaba/packages/?p=systemd.git;a=tag;h=refs/tags/208-alt0.M70T.5>) > > или лучше 208-alt0.M70P.7 (см. > > <http://git.altlinux.org/people/shaba/packages/?p=systemd.git;a=tag;h=refs/tags/208-alt0.M70P.7>)? ... > > 208-alt0.M70P.7 из p7/master Ok.
(В ответ на комментарий №11) > Всё сделанное вынесено в подпакет sysvinit-tmpfiles, конфликтующий с > systemd-sysvinit (защита от выполнения /etc/init.d/tmpfiles под systemd). А может проверять через /sbin/sd_booted? и не делать отдельный пакет? для защиты от запуска под systemd можно положить симлинк /lib/systemd/system/tmpfiles -> /dev/null (или на /lib/systemd/system/systemd-tmpfiles-setup.service )
(В ответ на комментарий №12) > (В ответ на комментарий №11) > > Всё сделанное вынесено в подпакет sysvinit-tmpfiles, конфликтующий с > > systemd-sysvinit (защита от выполнения /etc/init.d/tmpfiles под systemd). > > А может проверять через /sbin/sd_booted? и не делать отдельный пакет? То что надо! (Не знал про /sbin/sd_booted.) А то что ниже, пожалуй будет лишним: > для защиты от запуска под systemd можно положить симлинк > /lib/systemd/system/tmpfiles -> /dev/null (или на > /lib/systemd/system/systemd-tmpfiles-setup.service ) 228-alt2.2 (см. http://git.altlinux.org/people/solo/packages/?p=systemd.git;a=commit;h=ea5f7a1209576f171a54eac9a0926ec33d55c3f7) собирается в http://git.altlinux.org/tasks/156192/.
(В ответ на комментарий №11) ... > > 208-alt0.M70P.7 из p7/master В http://git.altlinux.org/tasks/156209/ прошу смотреть 208-alt0.M70T.7.1 (см. http://git.altlinux.org/people/solo/packages/?p=systemd.git;a=commit;h=ddd405a42742123345836e8b5e4e50c39c4f9678) на предмет регрессий. Относительно 208-alt0.M70P.7 там произведён откат на старые kmod и libcryptsetup, актуальные для t7.
(В ответ на комментарий №7) > > p7 уже не нужно трогать. > А в t7 подобные изменения отправить можно? "Под занавес" устраивать такие изменения и вносить разницу между p7/t7 не хотелось бы -- ты ведь можешь добавлять локальный репозиторий, нет?
(В ответ на комментарий №15) > (В ответ на комментарий №7) > > > p7 уже не нужно трогать. > > А в t7 подобные изменения отправить можно? > "Под занавес" устраивать такие изменения и вносить разницу между p7/t7 > не хотелось бы -- ты ведь можешь добавлять локальный репозиторий, нет? Будет ли допустимой разницей между p7/t7, если я на systemd-201-alt1.M70P.5 натяну предлагаемые изменения (но там нет systemd-utils, его тоже придётся выделять)? PS: Добавлять локальный репо не хотелось бы -- поддерживать полученную конструкцию не сильно удобно...
(В ответ на комментарий №16) > PS: Добавлять локальный репо не хотелось бы -- поддерживать полученную > конструкцию не сильно удобно... Там наверняка будет свой брендинг +/- ещё какие образоспецифичные пакеты, нет?
(В ответ на комментарий №17) > (В ответ на комментарий №16) > > PS: Добавлять локальный репо не хотелось бы -- поддерживать полученную > > конструкцию не сильно удобно... > Там наверняка будет свой брендинг +/- ещё какие образоспецифичные пакеты, нет? Нет, в этом месте нет такой специфики (и вносить её нехочу). Голый ALT там.
А на сизиф в преддверии p8 перебираться тоже не вариант? (ты не подумай, я сам сейчас такое отгружаю по одному проекту -- с заремареным sources.list -- потому как бэкпортить было бы от и до)
(В ответ на комментарий №19) > А на сизиф в преддверии p8 перебираться тоже не вариант? Такой вариант рассматриваю. Но без возможности предварительного тестирования он выглядит слишком стрёмно. А тестовые виртуалки станут доступны только после привода данного сервака в надёжно управляемое состояние...
(В ответ на комментарий №3) > 3. Скрипт /etc/cron.daily/tmpfiles, раз в сутки вызывающий /etc/init.d/tmpfiles > condclean. > > По моему так функционал systemd-tmpfiles под sysvinit будет соответствовать > большей части его же функционала под systemd. (За бортом осталась только > очистка каталогов через 15 мин. после старта. Что не критично на мой взгляд.) > Непонятно только как исключить конфликт с unit`ами > systemd-tmpfiles-{start,clean}.service, при работе под systemd... Вынести всё > это в пакет systemd-tmpfiles-sysvinit, зависящий от sysvinit? а зачем поддержку cron делаете? Обычно чистить достаточно только /tmp и /var/tmp, а это и так делает stmpclean. Тогда еще надо добавить Provides и Obsoletes: stmpclean в пакет systemd-utils, иначе они могут подраться.
(В ответ на комментарий №16) > (В ответ на комментарий №15) > > (В ответ на комментарий №7) > > > > p7 уже не нужно трогать. > > > А в t7 подобные изменения отправить можно? > > "Под занавес" устраивать такие изменения и вносить разницу между p7/t7 > > не хотелось бы -- ты ведь можешь добавлять локальный репозиторий, нет? > > Будет ли допустимой разницей между p7/t7, если я на systemd-201-alt1.M70P.5 > натяну предлагаемые изменения (но там нет systemd-utils, его тоже придётся > выделять)? В http://git.altlinux.org/tasks/156715/ собран systemd-201-alt1.M70T.2.1 (см. http://git.altlinux.org/people/solo/packages/?p=systemd.git;a=commit;h=e22546f92d4edc8540d4329c8fade33b09dd0d01). Отличия от стандартного для t7 systemd-201-alt1.M70T.2: 1. Выделен подпакет systemd-utils -- портировано переносом коммитов с ветки, из которой собирался systemd-208-alt0.M70T.7.2 (см. http://git.altlinux.org/people/solo/packages/?p=systemd.git;a=commit;h=aaf66420eed2a910be005d144e6c59ca525b35af). 2. В подпакет systemd-utils добавлены init и cron скрипты для systemd-tmpfiles. 3. Пути к утилитам оставлены без изменений (нет переезда из /bin в /sbin). Прошу тестировать.
(В ответ на комментарий №21) > (В ответ на комментарий №3) > > > 3. Скрипт /etc/cron.daily/tmpfiles, раз в сутки вызывающий /etc/init.d/tmpfiles > > condclean. > > > > По моему так функционал systemd-tmpfiles под sysvinit будет соответствовать > > большей части его же функционала под systemd. (За бортом осталась только > > очистка каталогов через 15 мин. после старта. Что не критично на мой взгляд.) ... > > а зачем поддержку cron делаете? Обычно чистить достаточно только /tmp и > /var/tmp, а это и так делает stmpclean. На t7, stmpclean-0.3-alt3 чистит {,/var}/tmp, /var/cache/man и /var/catman. И нет автоматизированного способа расширить данный список (только через редактирование /etc/cron.daily/stmpclean). В этом плане systemd-tmpfiles более гибок: любой пакет может задать что и с каким периодом чистить, поместив соответствующий конфиг в tmpfiles.d/. > Тогда еще надо добавить Provides и Obsoletes: stmpclean в пакет systemd-utils, > иначе они могут подраться. Пусть дерутся. Максимум к чему это приведёт, если обе утилиты будут натравлены на один каталог -- в каталоге будут действовать минимальный период очистки из заданных. Не вижу к каким проблемам может перевести такая ситуация. (Кроме возможного недоумения администратора, знающего только про один из механизмов.) Смысл же от параллельной установки systemd-tmpfiles и stmpclean есть. stmpclean значительно удобнее использовать для разового удаления старых файлов из произвольного каталога, т. к. все необходимые параметры (время жизни и путь к каталогу) можно указать в строке вызова. А для systemd-tmpfiles -- необходим настроенный конфиг.
(В ответ на комментарий №22) ... > В http://git.altlinux.org/tasks/156715/ собран systemd-201-alt1.M70T.2.1 (см. > http://git.altlinux.org/people/solo/packages/?p=systemd.git;a=commit;h=e22546f92d4edc8540d4329c8fade33b09dd0d01). В http://git.altlinux.org/tasks/156715/ собрана исправленная версия предыдущего варианта -- systemd-201-alt1.M70T.2.2 (см. http://git.altlinux.org/people/solo/packages/?p=systemd.git;a=commit;h=27defdffd838d0e9c4d6e2a36bf3b181dd4aff30). (В systemd-201-alt1.M70T.2.1 попали не все unit файлы.)
(В ответ на комментарий №24) ... > В http://git.altlinux.org/tasks/156715/ собрана исправленная версия > предыдущего варианта -- systemd-201-alt1.M70T.2.2 (см. > http://git.altlinux.org/people/solo/packages/?p=systemd.git;a=commit;h=27defdffd838d0e9c4d6e2a36bf3b181dd4aff30). Тестирование systemd-201-alt1.M70T.2.2 показало, что заявленные цели достигнуты: под systemd и sysvinit нормально работают следующие конфигурации: а) /run, /var/run и /var/lock отдельные каталоги; б) /run каталог + симлинки /var/run -> /run и /var/lock -> /run/lock; Финальные подготовленные варианты, для соответствующих репозиториев, ждут одобрения: (отправлены на тестовую сборку) 1. Для Сизифа -- systemd-228-alt3 (см. http://git.altlinux.org/people/solo/packages/?p=systemd.git;a=commit;h=73373da6e0f745faba2914dad30ff9eb3643d7e1) в http://git.altlinux.org/tasks/156192/. 2. Для t7 -- systemd.git=201-alt1.M70T.3 (см. http://git.altlinux.org/people/solo/packages/?p=systemd.git;a=commit;h=378439186d6eb477bc5838f7beda3d01702121bc) в http://git.altlinux.org/tasks/156715/
sysvinit-tmpfiles-1.0-alt1 -> sisyphus: * Fri Feb 19 2016 Aleksey Avdeev <solo@altlinux> 1.0-alt1 - Remove tmpfiles init script (is old) * Wed Feb 10 2016 Aleksey Avdeev <solo@altlinux> 0.1-alt1 - Initial build for ALT Linux (ALT#31718)
(In reply to comment #2) > - для создания static-nodes в /dev используется systemd-tmpfiles под sysv из > /etc/rc.d/init.d/udevd Сейчас не работает. Я так понял, что нужно вместо: create_static_inodes() { mkdir -p /run/tmpfiles.d [ -x "$kmod" ] && $kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf [ -x "$systemd_tmpfiles" ] && $systemd_tmpfiles --prefix=/dev --create } делать: create_static_inodes() { mkdir -p /run/tmpfiles.d [ -x "$kmod" ] && $kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf [ -x "$systemd_tmpfiles" ] && $systemd_tmpfiles --prefix=/dev --create --boot } Не знаю, для каких версий помимо Sisyphus это актуально. Устройства не создаются, когда там восклицательные знаки (только с --boot обрабатываются) при таких версиях: -bash-4.3# rpm -qf /etc/init.d/udevd udev-233-alt1.x86_64 -bash-4.3# cat /run/tmpfiles.d/kmod.conf c! /dev/autofs 0600 - - - 10:235 c! /dev/fuse 0600 - - - 10:229 c! /dev/cuse 0600 - - - 10:203 c! /dev/btrfs-control 0600 - - - 10:234 d /dev/net 0755 - - - c! /dev/net/tun 0600 - - - 10:200 c! /dev/ppp 0600 - - - 108:0 c! /dev/userio 0600 - - - 10:240 c! /dev/uinput 0600 - - - 10:223 d /dev/mapper 0755 - - - c! /dev/mapper/control 0600 - - - 10:236 d /dev/vfio 0755 - - - c! /dev/vfio/vfio 0600 - - - 10:196 c! /dev/vhci 0600 - - - 10:137 c! /dev/uhid 0600 - - - 10:239 c! /dev/vhost-net 0600 - - - 10:238 d /dev/snd 0755 - - - c! /dev/snd/timer 0600 - - - 116:33 d /dev/snd 0755 - - - c! /dev/snd/seq 0600 - - - 116:1 -bash-4.3# rpm -qf /bin/kmod kmod-23-alt1.x86_64 -bash-4.3# и при таких: [root@vb ~]# cat /run/tmpfiles.d/kmod.conf c! /dev/autofs 0600 - - - 10:235 c! /dev/fuse 0600 - - - 10:229 c! /dev/cuse 0600 - - - 10:203 c! /dev/btrfs-control 0600 - - - 10:234 d /dev/net 0755 - - - c! /dev/net/tun 0600 - - - 10:200 c! /dev/ppp 0600 - - - 108:0 c! /dev/userio 0600 - - - 10:240 c! /dev/uinput 0600 - - - 10:223 d /dev/mapper 0755 - - - c! /dev/mapper/control 0600 - - - 10:236 d /dev/vfio 0755 - - - c! /dev/vfio/vfio 0600 - - - 10:196 c! /dev/vhci 0600 - - - 10:137 c! /dev/uhid 0600 - - - 10:239 c! /dev/vhost-net 0600 - - - 10:238 d /dev/snd 0755 - - - c! /dev/snd/timer 0600 - - - 116:33 d /dev/snd 0755 - - - c! /dev/snd/seq 0600 - - - 116:1 [root@vb ~]# man systemd-tmpfiles [root@vb ~]# rpm -qf /etc/init.d/udevd udev-232-alt1 [root@vb ~]# rpm -qf /bin/kmod kmod-21-alt1 [root@vb ~]# cut --fields=2 -d' ' </lib/modules/"$(uname -r)"/modules.devname | (cd /dev/; xargs ls -ld) ls: cannot access Device: No such file or directory ls: cannot access fuse: No such file or directory ls: cannot access cuse: No such file or directory ls: cannot access btrfs-control: No such file or directory ls: cannot access ppp: No such file or directory ls: cannot access userio: No such file or directory ls: cannot access uinput: No such file or directory ls: cannot access vfio/vfio: No such file or directory ls: cannot access vhci: No such file or directory ls: cannot access uhid: No such file or directory ls: cannot access vhost-net: No such file or directory ls: cannot access snd/timer: No such file or directory ls: cannot access snd/seq: No such file or directory crw------- 1 root root 10, 235 авг 8 23:13 autofs crw------- 1 root root 10, 236 авг 8 23:13 mapper/control crw-rw-rw- 1 root root 10, 200 авг 8 23:13 net/tun [root@vb ~]# Почувствовал это из-за отсутствия /dev/net/tun при работе libvirtd без systemd -- как у них: https://bugzilla.novell.com/show_bug.cgi?id=792178#c3 (libvirt should load tun module)
(In reply to comment #27) > (In reply to comment #2) > > > - для создания static-nodes в /dev используется systemd-tmpfiles под sysv из > > /etc/rc.d/init.d/udevd > > Сейчас не работает. Я так понял, что нужно вместо: Ошибочно переоткрыл этот баг, хотя этт был про всё кроме /dev/ как раз. Новая проблема с /dev/* -- https://bugzilla.altlinux.org/show_bug.cgi?id=34031 . После --boot (раньше --unsafe), внесённого начиная с версии 209 systemd.
