[sisyphus] systemd: path-based activation

[sisyphus] systemd: path-based activation

[Eugene Prokopiev]

Здравствуйте!

В процессе отладки altlinux-openresolv.* понял, что у меня вообще не
работает path-based activation либо я делаю что-то не так:

Вот простейший пример. Создаем файлы:

# cat file.path
[Unit]
Description=My path
RequiresMountsFor=/root
Before=paths.target shutdown.target
[Path]
PathChanged=/root/file.0
[Install]
WantedBy=multi-user.target

# cat file.service
[Unit]
Description=My service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'cat /root/file.0 > /root/file.1'
[Install]
WantedBy=multi-user.target

Перечитываем, запускаем, смотрим состояние:

[root@enp system]# systemctl daemon-reload
[root@enp system]# systemctl start file.path
[root@enp system]# systemctl status file.path
● file.path - My path
   Loaded: loaded (/etc/systemd/system/file.path; disabled; vendor
preset: disabled)
   Active: active (waiting) since Ср 2015-09-16 09:51:47 MSK; 4s ago
сен 16 09:51:47 enp.donpac.ru systemd[1]: Started My path.
[root@enp system]# systemctl status file.service
● file.service - My service
   Loaded: loaded (/etc/systemd/system/file.service; disabled; vendor
preset: disabled)
   Active: inactive (dead)

Теперь пишем в один файл и ожидаем увидеть результаты во втором:

# echo one > /root/file.0
# systemctl status file.service
● file.service - My service
   Loaded: loaded (/etc/systemd/system/file.service; disabled; vendor
preset: disabled)
   Active: active (exited) since Ср 2015-09-16 09:52:18 MSK; 9s ago
  Process: 1426 ExecStart=/bin/sh -c cat /root/file.0 > /root/file.1
(code=exited, status=0/SUCCESS)
 Main PID: 1426 (code=exited, status=0/SUCCESS)
сен 16 09:52:18 enp.donpac.ru systemd[1]: Starting My service...
сен 16 09:52:18 enp.donpac.ru systemd[1]: Started My service.
сен 16 09:52:18 enp.donpac.ru systemd[1]: Started My service.
сен 16 09:52:25 enp.donpac.ru systemd[1]: Started My service.
# cat /root/file.1
# echo two > /root/file.0
# systemctl status file.service
● file.service - My service
   Loaded: loaded (/etc/systemd/system/file.service; disabled; vendor
preset: disabled)
   Active: active (exited) since Ср 2015-09-16 09:52:18 MSK; 1min 54s ago
  Process: 1426 ExecStart=/bin/sh -c cat /root/file.0 > /root/file.1
(code=exited, status=0/SUCCESS)
 Main PID: 1426 (code=exited, status=0/SUCCESS)
сен 16 09:52:18 enp.donpac.ru systemd[1]: Starting My service...
сен 16 09:52:18 enp.donpac.ru systemd[1]: Started My service.
сен 16 09:52:18 enp.donpac.ru systemd[1]: Started My service.
сен 16 09:52:25 enp.donpac.ru systemd[1]: Started My service.
сен 16 09:54:11 enp.donpac.ru systemd[1]: Started My service.
# cat /root/file.1
#

Вручную разумеется все прекрасно:

# cat /root/file.0 > /root/file.1
# cat /root/file.1
two
#

Может я что-то делаю не так?

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

On Wed, Sep 16, 2015 at 10:17:11AM +0300, Eugene Prokopiev wrote:

> [Unit]
> Description=My service
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/sh -c 'cat /root/file.0 > /root/file.1'
> [Install]
> WantedBy=multi-user.target

Насколько понимаю:

Раз oн RemainAfterExit, то его повторный запуск, естественно, невозможен.
А раз он еще и WantedBy=multi-user.target, то он стартует один раз.

Так что убери RemainAfterExit, да и секцию Install тоже.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

16 сентября 2015 г., 10:29 Денис Смирнов написал:

> Раз oн RemainAfterExit, то его повторный запуск, естественно, невозможен

Точно

> А раз он еще и WantedBy=multi-user.target, то он стартует один раз.

Это уже лечится с помощью Also=

Спасибо.

altlinux-openresolv.* впрочем все равно не смог заставить работать,
зато попутно изготовил:

# cat /etc/systemd/system/altlinux-simpleresolv.service
[Unit] Description=Update /etc/resolv.conf from systemd-resolved
ConditionFileNotEmpty=/run/systemd/resolve/resolv.conf
RequiresMountsFor=/etc /run/systemd/resolve
Requires=systemd-resolved.service
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'cat /run/systemd/resolve/resolv.conf > /etc/resolv.conf'
[Install] WantedBy=multi-user.target
Also=altlinux-simpleresolv.path

# cat /etc/systemd/system/altlinux-simpleresolv.path
[Unit]
Description=Update /etc/resolv.conf from systemd-resolved
DefaultDependencies=no
RequiresMountsFor=/etc /run/systemd/resolve
Before=paths.target
[Path]
PathModified=/run/systemd/resolve/resolv.conf
[Install]
WantedBy=multi-user.target

В ситуации, когда сетью полностью управляет systemd-networkd, этот
вариант устраивает меня гораздо больше. Нельзя ли запакетить это в
состав systemd-networkd?

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

16 сентября 2015 г., 14:39 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:

> а чем не устраивает просто симлинк /etc/resolv.conf ->
> /run/systemd/resolve/resolv.conf ?

Он появляется в чруте /var/resolv, но там нет
/run/systemd/resolve/resolv.conf - и в результате перестает работать
ping

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

21 сентября 2015 г., 23:14 Alexey Shabalin написал:

> Будьте добры, попробуйте altlinux-openresolv.service такого содержания:

<skip>

> Т.е. надо убрать RemainAfterExit=yes и ExecStop=

Не работает, и чуть раньше что-то подобное я уже пробовал. Работает,
если в моем altlinux-simpleresolv.service (который я сделал по
аналогии с работающим altlinux-libresolv.service) заменить ExecStart
на resolvconf вместо копирования.

Но altlinux-simpleresolv.* было бы неплохо добавить вне зависимости от
работоспособности altlinux-openresolv.*

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Michael Shigorin]

On Thu, Nov 19, 2015 at 03:23:10PM +0300, Alexey Shabalin wrote:
> Так же я отключил в этой сборке преднастроенные DNS и NTP от
> google. Для домашней машинки google'овые может и хороши, а вот
> в корпоративной среде никто спасибо не скажет, если машинка
> неожиданно начнёт слать запросы в google.

Да уж.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

19 ноября 2015 г., 15:23 Alexey Shabalin написал:

> Я обновил  altlinux-openresolv в systemd-228-alt1. Протестируйте пожалуйста.

Смогу обновить машину, на которой все это происходило, только через
неделю :( А altlinux-simpleresolv вы добавлять не хотите?

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

20 ноября 2015 г., 16:50 Alexey Shabalin написал:

> Мне хотелось бы, что бы единственный вариант работал нормально. Если он
> будет работать нормально, то и необходимости в  altlinux-simpleresolv не
> будет.

Работать-то мы его заставим, однако openresolv мне всегда казался
лишней сущностью - и тем более в времена systemd, который уже подтянул
под себя кучу вариантов сетевых подключений и останавливаться не
собирается.

Я все-таки считаю, что если что-то можно сделать проще, и это не
выйдет боком - значит это нужно сделать. Жаль, что такая точка зрения
непопулярна: вон я и мантейнера dnsmasq не сумел уговорить сделать
опциональным dnsmasq-helper, хотя openresolv все-таки стал
необязательным - https://bugzilla.altlinux.org/show_bug.cgi?id=31277

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

20 ноября 2015 г., 18:55 Alexey Shabalin написал:

>> Работать-то мы его заставим, однако openresolv мне всегда казался
>> лишней сущностью - и тем более в времена systemd, который уже подтянул
>> под себя кучу вариантов сетевых подключений и останавливаться не
>> собирается.
>>
> Я в принципе не против. Только не совсем понимаю какие куда конфликты(в
> rpm-пакеты, в unit-файлы) и ручки для переключения разных схем(control? или
> какой-то умный автовыбор).

Меня бы устроило отсутствие каких бы то ни было дополнительных ручек и
тем более конфликтов :) Просто пользователь или релиз-менеджер
дистрибутива может сказать systemctl enable
altlinux-simpleresolv|altlinux-openresolv в зависимости от
потребности.

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

.

20 ноября 2015 г., 19:54 пользователь Eugene Prokopiev <enp@itx.ru> написал:
> 20 ноября 2015 г., 18:55 Alexey Shabalin написал:
>
>>> Работать-то мы его заставим, однако openresolv мне всегда казался
>>> лишней сущностью - и тем более в времена systemd, который уже подтянул
>>> под себя кучу вариантов сетевых подключений и останавливаться не
>>> собирается.
>>>
>> Я в принципе не против. Только не совсем понимаю какие куда конфликты(в
>> rpm-пакеты, в unit-файлы) и ручки для переключения разных схем(control? или
>> какой-то умный автовыбор).
>
> Меня бы устроило отсутствие каких бы то ни было дополнительных ручек и
> тем более конфликтов :) Просто пользователь или релиз-менеджер
> дистрибутива может сказать systemctl enable
> altlinux-simpleresolv|altlinux-openresolv в зависимости от
> потребности.

Кстати возможен и автовыбор, критерий - наличие /sbin/resolvconf. Т.е.
в автостарт можно ставить оба варианта, а отрабатывать будет один из
них.

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

23 декабря 2015 г., 11:10 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:

> Для начала хотел бы полностью сформировать общую картину. Давайте опишем все
> возможные варианты, сценарии использования. Я сам могу многое не знать или
> видеть под неправильным углом. Например, почему openresolv в контейнере
> лишняя сущность? Если openresolv опционален, то почему на него существуют
> зависимости (NetworkManager? - хотя это тоже лишнее в контейнере:)

openresolv полезен в тех редких случаях, когда у нас много желающих
модифицировать resolv.conf. Соответственно, если таких желающих нет
(полностью статическая конфигурация - а это значительная часть
серверов и контейнеров), то openresolv не нужен. Если таких желающих
не более одного (например DHCP-клиент), то openresolv тоже не нужен.
Одним из желающих является systemd-resolved, однако если все сетевые
интерфейсы управляются посредством systemd-networkd, то
systemd-resolved опять же будет единственным.

Особых зависимостей на openresolv нет, от dnsmasq она была недавно
оторвана, а в базовой системе таких зависимостей тем более нет. По
крайней мере у меня openresolv, как правило, не установлен.

> Кажется, я с самого появления altlinux-openresolv предлагал его упаковать в
> пакет openresolv. Мне тогда отказали, с аргументом, что это нужно только
> systemd - вот пусть он и носит с собой. Оказывается от openresolv можно
> отказаться, и тогда altlinux-openresolv повиснет в воздухе. Моя позиция, что
> пакет сам должен обеспечивать себе работу под любыми init-системами,
> содержать в себе все необходимое для запуска и работы. Евгений, давайте
> предположим, altlinux-openresolv переедет в openresolv, то куда паковать
> altlinux-simpleresolv?

Вне зависимости от того, куда класть altlinux-openresolv,
altlinux-simpleresolv нужно класть в systemd-networkd (еще проще было
бы симлинком обойтись, но увы). Вполне можно представить себе систему
с systemd, NetworkManager и без systemd-networkd - тогда
altlinux-simpleresolv будет бесполезен, как и altlinux-openresolv,
кстати, по причине отсутствия systemd-resolved. Поэтому в идеале
altlinux-openresolv вообще стоило бы в какой-то отдельный пакет
паковать :)

> Хотелось бы сделать универсально, продумать все варианты, работающее
> автоматически без дополнительного вмешательства. Хак "лишь бы заработало
> сейчас" меня не устраивает.

Логичная позиция, двумя руками за, тем более что кое-как и сейчас работает :)

Автоматику я чуть раньше описывал - можно полагаться на
присутствие/отсутствие файла /sbin/resolvconf. Соответственно
altlinux-openresolv и altlinux-simpleresolv могут быть по дефолту
включены одновременно, но запустится только один из них.

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Afanasov Dmitry]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Wed, Dec 23, 2015 at 12:22:59PM +0300, Eugene Prokopiev wrote:
> Вполне можно представить себе систему с systemd, NetworkManager и без
> systemd-networkd
это почти любой сизиф, поставленный N лет назад (до появления сети в
systemd). также подобное может случиться текущем переключении с sysvinit
на systemd при использовании etcnet.

до конфигураций без systemd-networkd очень легко приехать
последовательными dist-upgrade'ами.

у меня два ноута на systemd + NetworkManager + etcnet, только вчера
обновил. ещё одну рабочую станцию хочу переводить с sysvinit а systemd.
что будет, интересно.

-- 
С уважением
Афанасов Дмитрий

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd: path-based activation

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

On Fri, Nov 20, 2015 at 06:26:26PM +0300, Eugene Prokopiev wrote:

> Работать-то мы его заставим, однако openresolv мне всегда казался
> лишней сущностью - и тем более в времена systemd, который уже подтянул
> под себя кучу вариантов сетевых подключений и останавливаться не
> собирается.

systemd хорош тем, что просто работает в простых случаях. Однако что
etcnet, что openresolv несравнимо гибче -- были, есть, и будут, ибо
приоритеты у systemd несколько другие.

Поэтому да, на "обычном десктопе" или в простой VE openresolv может быть и
лишней сущностью (как и etcnet), только вот при желании хоть чуть-чуть
отклониться от линии партии -- сразу придется вспомнить и про etcnet, и
про openresolv, и про другие "несовременные" и "не модные", зато гибкие и
работающие штуки.

> Я все-таки считаю, что если что-то можно сделать проще, и это не
> выйдет боком - значит это нужно сделать. Жаль, что такая точка зрения
> непопулярна: вон я и мантейнера dnsmasq не сумел уговорить сделать
> опциональным dnsmasq-helper, хотя openresolv все-таки стал
> необязательным - https://bugzilla.altlinux.org/show_bug.cgi?id=31277

:(

-- 
С уважением, Денис

http://mithraen.ru/


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [sisyphus] systemd: path-based activation

[Anton Gorlov]

21.11.2015 17:10, Денис Смирнов пишет:
> Поэтому да, на "обычном десктопе" или в простой VE openresolv может быть и
> лишней сущностью (как и etcnet), только вот при желании хоть чуть-чуть
> отклониться от линии партии -- сразу придется вспомнить и про etcnet, и
> про openresolv, и про другие "несовременные" и "не модные", зато гибкие и
> работающие штуки.

Именно.
В systemd-networkd я так и не нашёл как там заставить PPpoE работать
через ядерный pppoe
В etcnet правда тоже небольшой патчик..но хотя бы нашлось куда и как

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

20 ноября 2015 г., 15:15 пользователь Eugene Prokopiev <enp@itx.ru> написал:
> 19 ноября 2015 г., 15:23 Alexey Shabalin написал:
>
>> Я обновил  altlinux-openresolv в systemd-228-alt1. Протестируйте пожалуйста.
>
> Смогу обновить машину, на которой все это происходило, только через
> неделю :(

Вот добрался наконец :)

Однако вижу, что altlinux-openresolv теперь зависит от
systemd-networkd-wait-online, который как раз после обновления на
systemd-228-alt1
стал странно себя вести - пишет при загрузке 'A start job is running
for Wait for Network to be configured (1min 18s / no limit)', а будучи
запущенным руками в лучшем случае дохнет по таймауту либо же просто
висит. Как это лечить?

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

1 декабря 2015 г., 13:50 пользователь Eugene Prokopiev <enp@itx.ru> написал:
> 20 ноября 2015 г., 15:15 пользователь Eugene Prokopiev <enp@itx.ru> написал:
>> 19 ноября 2015 г., 15:23 Alexey Shabalin написал:
>>
>>> Я обновил  altlinux-openresolv в systemd-228-alt1. Протестируйте пожалуйста.
>>
>> Смогу обновить машину, на которой все это происходило, только через
>> неделю :(
>
> Вот добрался наконец :)
>
> Однако вижу, что altlinux-openresolv теперь зависит от
> systemd-networkd-wait-online, который как раз после обновления на
> systemd-228-alt1
> стал странно себя вести - пишет при загрузке 'A start job is running
> for Wait for Network to be configured (1min 18s / no limit)', а будучи
> запущенным руками в лучшем случае дохнет по таймауту либо же просто
> висит. Как это лечить?

# systemctl status systemd-networkd-wait-online
● systemd-networkd-wait-online.service - Wait for Network to be Configured
   Loaded: loaded
(/lib/systemd/system/systemd-networkd-wait-online.service; disabled;
vendor preset: disabled)
   Active: failed (Result: exit-code) since Вт 2015-12-01 13:41:38
MSK; 13min ago
     Docs: man:systemd-networkd-wait-online.service(8)
 Main PID: 549 (code=exited, status=1/FAILURE)

дек 01 13:39:37 enp systemd-networkd-wait-online[549]: ignoring: lo
дек 01 13:39:37 enp systemd-networkd-wait-online[549]: ignoring: lo
дек 01 13:39:37 enp systemd-networkd-wait-online[549]: ignoring: lo
дек 01 13:39:37 enp systemd-networkd-wait-online[549]: ignoring: lo
дек 01 13:39:37 enp systemd-networkd-wait-online[549]: ignoring: lo
дек 01 13:39:37 enp systemd-networkd-wait-online[549]: ignoring: lo
дек 01 13:41:38 enp systemd[1]: systemd-networkd-wait-online.service:
Main process exited, code=exited, status=1/FAILURE
дек 01 13:41:38 enp systemd[1]: Failed to start Wait for Network to be
Configured.
дек 01 13:41:38 enp systemd[1]: systemd-networkd-wait-online.service:
Unit entered failed state.
дек 01 13:41:38 enp systemd[1]: systemd-networkd-wait-online.service:
Failed with result 'exit-code'.

При этом 'A start job is running for Wait for Network ...' на первой
консоли так и висит.

Да, сетевая конфигурация там относительно запутанная: включает вланы и маквланы.

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

1 декабря 2015 г., 14:20 Alexey Shabalin написал:

>> Да, сетевая конфигурация там относительно запутанная: включает вланы и
>> маквланы.
>
>
> покажите вывод  networkctl

 networkctl
IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           carrier     configured
  2 enp4s0           ether              carrier     configuring
  3 enp4s0.900       ether              routable    configuring
  4 enp4s0.1610      ether              routable    configuring
  5 enp4s0.3         ether              routable    configuring
  6 enp4s0.791       ether              carrier     configuring
  7 enp4s0.20        ether              routable    configuring
  8 enp4s0.10        ether              routable    configuring
  9 enp4s0.791.0     ether              routable    configuring
 10 ppp0             ppp                routable    unmanaged

10 links listed.

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

1 декабря 2015 г., 15:54 Eugene Prokopiev написал:
> 1 декабря 2015 г., 14:20 Alexey Shabalin написал:
>
>>> Да, сетевая конфигурация там относительно запутанная: включает вланы и
>>> маквланы.
>>
>>
>> покажите вывод  networkctl
>
>  networkctl
> IDX LINK             TYPE               OPERATIONAL SETUP
>   1 lo               loopback           carrier     configured
>   2 enp4s0           ether              carrier     configuring
>   3 enp4s0.900       ether              routable    configuring
>   4 enp4s0.1610      ether              routable    configuring
>   5 enp4s0.3         ether              routable    configuring
>   6 enp4s0.791       ether              carrier     configuring
>   7 enp4s0.20        ether              routable    configuring
>   8 enp4s0.10        ether              routable    configuring
>   9 enp4s0.791.0     ether              routable    configuring
>  10 ppp0             ppp                routable    unmanaged
>
> 10 links listed.

А правда, почему все интерфейсы (кроме lo) configuring, а не
configured? Они доступны и даже NAT из enp4s0.791.0 в остальные
интерфейсы работает.

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

1 декабря 2015 г., 16:19 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:
>
>
> 1 декабря 2015 г., 15:58 пользователь Eugene Prokopiev <enp@itx.ru> написал:
>>
>> 1 декабря 2015 г., 15:54 Eugene Prokopiev написал:
>> > 1 декабря 2015 г., 14:20 Alexey Shabalin написал:
>> >
>> >>> Да, сетевая конфигурация там относительно запутанная: включает вланы и
>> >>> маквланы.
>> >>
>> >>
>> >> покажите вывод  networkctl
>> >
>> >  networkctl
>> > IDX LINK             TYPE               OPERATIONAL SETUP
>> >   1 lo               loopback           carrier     configured
>> >   2 enp4s0           ether              carrier     configuring
>> >   3 enp4s0.900       ether              routable    configuring
>> >   4 enp4s0.1610      ether              routable    configuring
>> >   5 enp4s0.3         ether              routable    configuring
>> >   6 enp4s0.791       ether              carrier     configuring
>> >   7 enp4s0.20        ether              routable    configuring
>> >   8 enp4s0.10        ether              routable    configuring
>> >   9 enp4s0.791.0     ether              routable    configuring
>> >  10 ppp0             ppp                routable    unmanaged
>> >
>> > 10 links listed.
>>
>> А правда, почему все интерфейсы (кроме lo) configuring, а не
>> configured? Они доступны и даже NAT из enp4s0.791.0 в остальные
>> интерфейсы работает.
>
>
> networkctl  status enp4s0 ?
> networkctl  status enp4s0.900 ?
> и покажите настройки какого нибудь интерфейса.

# networkctl status enp4s0
● 2: enp4s0
       Link File: /lib/systemd/network/99-default.link
    Network File: /etc/systemd/network/trunk.network
            Type: ether
           State: carrier (configuring)
            Path: pci-0000:04:00.0
          Driver: r8169
          Vendor: Realtek Semiconductor Co., Ltd.
           Model: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
      HW Address: 8c:89:a5:63:9c:8e (Micro-Star INT'L CO., LTD)
             MTU: 1500
# networkctl status enp4s0.900
● 3: enp4s0.900
       Link File: /lib/systemd/network/99-default.link
    Network File: /etc/systemd/network/silmaril.network
            Type: ether
           State: routable (configuring)
          Driver: 802.1Q VLAN Support
      HW Address: be:25:67:57:4b:26
             MTU: 1500
         Address: 10.11.80.181

# cat /etc/systemd/network/trunk.network
[Match]
Name=enp4s0
[Network]
VLAN=enp4s0.3
VLAN=enp4s0.10
VLAN=enp4s0.20
VLAN=enp4s0.791
VLAN=enp4s0.900
VLAN=enp4s0.1610

# cat /etc/systemd/network/silmaril.netdev
[NetDev]
Name=enp4s0.900
Kind=vlan
[VLAN]
Id=900

# cat /etc/systemd/network/silmaril.network
[Match]
Name=enp4s0.900
[Network]
Address=10.11.80.181/22

> я так понимаю, что если хотя бы один интерфейс перейдёт в  configured, то
> systemd-networkd-wait-online закончится.

Вероятно да, но как этого добиться?

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Eugene Prokopiev]

1 декабря 2015 г., 16:50 пользователь Alexey Shabalin
<a.shabalin@gmail.com> написал:

> попробуй добавить в
> [Network]
> LinkLocalAddressing=no

Спасибо, оно! Интерфейсы стали configured, altlinux-openresolv.service
отработал.

Нельзя ли только сделать это разом для всех интерфейсов, а еще лучше по дефолту?

-- 
WBR,
Eugene Prokopiev

Re: [sisyphus] systemd: path-based activation

[Anton Gorlov]

02.12.2015 18:11, Alexey Shabalin пишет:
> 
> тоже об этом думаю. сейчас дефолт LinkLocalAddressing=ipv6.
> Думаю сделаю дефолт LinkLocalAddressing=no.
> Есть возражения? кому нужен ipv6, тот сам это включит.
> 

Алексей..а не подскажешь ли часом как в systemd-networkd настраивать
PPPoE  в "ядерном" режиме?

Re: [sisyphus] systemd: path-based activation

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

On Tue, Dec 01, 2015 at 01:50:52PM +0300, Eugene Prokopiev wrote:

> Однако вижу, что altlinux-openresolv теперь зависит от
> systemd-networkd-wait-online, который как раз после обновления на
> systemd-228-alt1
> стал странно себя вести - пишет при загрузке 'A start job is running
> for Wait for Network to be configured (1min 18s / no limit)', а будучи
> запущенным руками в лучшем случае дохнет по таймауту либо же просто
> висит. Как это лечить?

А зачем вообще эта зависимость? 

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]