[sisyphus] systemd-network

[Mikhail Efremov]

On Wed, 13 Aug 2014 00:11:21 +0400 Денис Смирнов wrote:
> On Tue, Aug 12, 2014 at 07:41:30PM +0400, Mikhail Efremov wrote:
> 
> >> race может быть только в одном случае -- если модифицируется с небольшим
> >> интервалом, скажем, /etc/resolv.conf и /etc/hosts. Тогда, если второй файл
> >> был изменен после запуска, но до завершения юнита с синхронизацией --
> >> повторно он вызван не будет.
> > Я про race при одновременном запуске из юнит-файла и из хука для
> > resolvconf'а. Это всегда будет происходить одновременно при
> > изменении /etc/resolv.conf resolvconf'ом.
> 
> Два приложения пишут в один и тот же файл одни и те же данные. Предполагаю
> что это не приведет к повреждению данных.

При одновременном доступе к одному и тому же ресурсу проблемы могут
быть всегда.

> Хотя, конечно, хорошо бы отучить openresolv от ручного вызова
> update_chrooted при работе из под systemd.

Он просто запускает хуки из /etc/hooks/resolv.conf.d/ при
изменении /etc/resolv.conf. Положить туда хук может кто угодно (сейчас
там только хуки из пакетов avahi-daemon и chrooted, но могут появиться
и другие). И если хочется делать что-то подобное без resolvconf, то
запускать надо бы именно эти хуки (правда resolvconf может
экспортировать туда некоторые переменные, но существующие хуки никаких
resolvconf-специфичных переменных не используют), а не только прибитый
гвоздями в юнит-файле update_chrooted.
Вообще вариантов несколько:
1. Считать, что resolvconf используется всегда и тогда вообще не надо
следить за /etc/resolv.conf, resolvconf все сделает сам. Мне кажется,
что это предпочтительный вариант в данном случае.
2. При изменении /etc/resolv.conf проверять наличие /sbin/resolvconf и
ничего не делать если он присутствует.
3. В resolvconf не запускать хуки при наличие systemd. Мне сильно не
нравится этот вариант, resolvconf вообще не должны заботить такие вещи.
Делать так - только разводить бардак и странные неочевидные хаки.

-- 
WBR, Mikhail Efremov