LINUX.ORG.RU
ФорумAdmin

Запуск сервиса systemd после загрузки сети

 ,


3

2

Други, подскажите

С помощь automount от systemd на клиентских машинах при загрузке монтируется удаленное хранилище по nfs.

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

Так вот, из-за того что этот сервис (точнее его запускающий файл) хранится на удаленном хранилище, то при перезагрузке клиента он не запускается.

Как мне сделать так, чтобы этот сервис запускался только тогда, когда клиентская машина уже точно находится в сети и хранилище примонтировано?

А как сейчас выглядит сервис и как монтируется хранилище? Вообще смотри в сторону RequiresMountsFor= и After=network-online.target.

gasinvein ★★★
()
Последнее исправление: gasinvein (всего исправлений: 1)

когда клиентская машина уже точно находится в сети

Wants=network-online.target
After=network-online.target

и хранилище примонтировано

RequiresMountsFor=/path/to/files
intelfx ★★★★★
()
Ответ на: комментарий от intelfx

когда клиентская машина уже точно находится в сети

Wants=network-online.target
After=network-online.target

С таким конфигом юнит не ждёт, пока сеть появится «по-настоящему». Сетевой интерфейс онлайн, но IP-адреса ещё нет, потому что на получение адреса по DHCP нужно время.

Чтобы это побороть, используют костыль с automount-юнитами. По крайней мере, я другого работающего не нашёл.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Сетевой интерфейс онлайн, но IP-адреса ещё нет, потому что на получение адреса по DHCP нужно время.

network-online.target примерно за этим и сделали.

s-n-w-o.s по крайней мере ждёт перехода в состояние «configured», т. е. именно когда уже есть адрес и всё такое.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

network-online.target примерно за этим и сделали.

Очень хорошо. А systemd-networkd-wait-online.service зачем тогда ещё сделали? Чтобы уж наверняка? :-D

Да и страдания страдальцев в интернете ищутся. Не помогает им и мне network-online.target.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Wants не Requires

Здесь это не имеет значения. Неявная зависимость порядка всё равно добавляется.

Да и какая разница, если всё равно не работает?

n-o.t не магический, это всего лишь «интерфейс».

Да и страдания страдальцев в интернете ищутся. Не помогает им и мне network-online.target.

Делать systemctl enable $NETWORK_TOOL-wait-online.service страдальцы не пробовали?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Значит, что-то ещё не делали или делали неправильно

Спасибо, кэп.

Попробовал сейчас у себя сделать oneshot сервис, который плюёт вывод ip a в лог. Сделал ему After=network-online.target и Wants=network-online.target. Включил логирование systemd побольше, чтобы в лог ядра сыпалось. Вижу

[    3.744823] systemd-networkd[1275]: eth0: Gained IPv6LL
[    3.750849] systemd-networkd-wait-online[1284]: ignoring: lo
[    3.755618] systemd[1]: Started Wait for Network to be Configured.
[    3.761485] systemd[1]: Reached target Network is Online.

Вижу потом запуск моего сервиса, вижу, что в выводе ip a нет IPv4 адреса. Адрес появляется, но чуточку позже. IPv6 в виртуалку не настроен.

Ну и как тогда правильно?

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

УМВР.

$ systemctl cat test.service
# /etc/systemd/system/test.service
[Unit]
Wants=network-online.target
After=network.target network-online.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c '/usr/bin/ip addr; /usr/bin/ip route'
$ systemctl list-dependencies test.service
test.service
● ├─system.slice
● ├─network-online.target
● │ └─NetworkManager-wait-online.service
● └─sysinit.target
<...>
$ journalctl -b -u test.service
-- Logs begin at Fri 2019-03-08 10:46:21 MSK, end at Wed 2019-04-03 01:11:32 MSK. --
апр 03 01:11:25 able systemd[1]: Starting test.service...
апр 03 01:11:25 able sh[1718]: 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
апр 03 01:11:25 able sh[1718]:     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
апр 03 01:11:25 able sh[1718]:     inet 127.0.0.1/8 scope host lo
апр 03 01:11:25 able sh[1718]:        valid_lft forever preferred_lft forever
апр 03 01:11:25 able sh[1718]:     inet6 ::1/128 scope host
апр 03 01:11:25 able sh[1718]:        valid_lft forever preferred_lft forever
апр 03 01:11:25 able sh[1718]: 2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
апр 03 01:11:25 able sh[1718]:     link/ether fc:77:74:eb:23:64 brd ff:ff:ff:ff:ff:ff
апр 03 01:11:25 able sh[1718]:     inet 10.196.254.173/24 brd 10.196.254.255 scope global dynamic noprefixroute wlp2s0
апр 03 01:11:25 able sh[1718]:        valid_lft 43200sec preferred_lft 43200sec
апр 03 01:11:25 able sh[1718]:     inet6 fd68:fd4b:10b3:0:ed17:3ab4:cd4e:550c/64 scope global tentative noprefixroute
апр 03 01:11:25 able sh[1718]:        valid_lft forever preferred_lft forever
апр 03 01:11:25 able sh[1718]:     inet6 2a02:2168:8380:e100:7800:cc37:8fe8:b0ea/64 scope global tentative dynamic noprefixroute
апр 03 01:11:25 able sh[1718]:        valid_lft 1782sec preferred_lft 1782sec
апр 03 01:11:25 able sh[1718]:     inet6 fe80::d05a:a9bc:b0e:a4e1/64 scope link noprefixroute
апр 03 01:11:25 able sh[1718]:        valid_lft forever preferred_lft forever
апр 03 01:11:25 able sh[1718]: 3: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
апр 03 01:11:25 able sh[1718]:     link/ether 8c:16:45:e6:bf:48 brd ff:ff:ff:ff:ff:ff
апр 03 01:11:25 able sh[1718]: 4: wwp0s20f0u6i12: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
апр 03 01:11:25 able sh[1718]:     link/ether 6e:89:10:9e:80:41 brd ff:ff:ff:ff:ff:ff
апр 03 01:11:25 able sh[1718]: default via 10.196.254.1 dev wlp2s0 proto dhcp metric 20600
апр 03 01:11:25 able sh[1718]: 10.196.254.0/24 dev wlp2s0 proto kernel scope link src 10.196.254.173 metric 600
апр 03 01:11:25 able systemd[1]: test.service: Succeeded.
апр 03 01:11:25 able systemd[1]: Started test.service.
апр 03 01:11:25 able systemd[1]: test.service: Consumed 4ms CPU time, no IP traffic.
$ systemctl status test.service
● test.service
   Loaded: loaded (/etc/systemd/system/test.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Wed 2019-04-03 01:11:25 MSK; 4min 12s ago
  Process: 1718 ExecStart=/bin/sh -c /usr/bin/ip addr; /usr/bin/ip route (code=exited, status=0/SUCCESS)
 Main PID: 1718 (code=exited, status=0/SUCCESS)
       IP: 0B in, 0B out
      CPU: 4ms

апр 03 01:11:25 able sh[1718]:        valid_lft forever preferred_lft forever
апр 03 01:11:25 able sh[1718]: 3: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
апр 03 01:11:25 able sh[1718]:     link/ether 8c:16:45:e6:bf:48 brd ff:ff:ff:ff:ff:ff
апр 03 01:11:25 able sh[1718]: 4: wwp0s20f0u6i12: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
апр 03 01:11:25 able sh[1718]:     link/ether 6e:89:10:9e:80:41 brd ff:ff:ff:ff:ff:ff
апр 03 01:11:25 able sh[1718]: default via 10.196.254.1 dev wlp2s0 proto dhcp metric 20600
апр 03 01:11:25 able sh[1718]: 10.196.254.0/24 dev wlp2s0 proto kernel scope link src 10.196.254.173 metric 600
апр 03 01:11:25 able systemd[1]: test.service: Succeeded.
апр 03 01:11:25 able systemd[1]: Started test.service.
апр 03 01:11:25 able systemd[1]: test.service: Consumed 4ms CPU time, no IP traffic.
$ systemctl status NetworkManager-wait-online
● NetworkManager-wait-online.service - Network Manager Wait Online
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager-wait-online.service; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2019-04-03 01:11:25 MSK; 12s ago
     Docs: man:nm-online(1)
  Process: 857 ExecStart=/usr/bin/nm-online -s -q --timeout=30 (code=exited, status=0/SUCCESS)
 Main PID: 857 (code=exited, status=0/SUCCESS)
       IP: 0B in, 0B out
      CPU: 165ms

апр 03 01:11:14 able systemd[1]: Starting Network Manager Wait Online...
апр 03 01:11:25 able systemd[1]: Started Network Manager Wait Online.
intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от i-rinat
[    3.750849] systemd-networkd-wait-online[1284]: ignoring: lo
[    3.755618] systemd[1]: Started Wait for Network to be Configured.
[    3.761485] systemd[1]: Reached target Network is Online.

systemd-networkd-wait-online

У тебя сетью точно networkd рулит?

intelfx ★★★★★
()
Ответ на: комментарий от i-rinat

«ВР» относится к тому, что в моей системе состояния гонки нет, что очевидно из таймштампов. А что ты делаешь не так — ищи сам, потому что подробностей ты никаких не предоставил, даже после явного вопроса с моей стороны, только сидишь и пытаешься троллить.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

даже после явного вопроса с моей стороны

Ты задаёшь вопросы, для ответа на которые нужно сначала самому во всём разобраться и выяснить в чём дело. Очевидно, в итоге всё к этому и сводится — разобраться или забить.

только сидишь и пытаешься троллить.

Ага, и это мне говорит человек, скативший обсуждение в «УМВР». Да-да, это я тут троллю, ага.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Мне кажется, я догадываюсь, что именно ты делаешь не так.

systemd-networkd-wait-online.service(8):

By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to gain a carrier.

(emphasis mine)

В то же время, у тебя

Я его сервис включил, но не проверял, что именно он там делает.

откуда следует, что сеть у тебя запускает отнюдь не networkd. В этой ситуации s-n-w-o.s будет делать ровно ничего.

Тебе нужно взять того демона, который у тебя рулит сетью, найти (или написать) для него собственный wait-online и добавить его в зависимости к network-online.target.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от i-rinat

Ты задаёшь вопросы, для ответа на которые нужно сначала самому во всём разобраться и выяснить в чём дело

Ага, вопрос «управляет ли твоей сетью networkd» настолько сложный, что проще самому всё сделать.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Ага, вопрос «управляет ли твоей сетью networkd» настолько сложный

Вообще, да. Чтобы на такие вопросы уверенно отвечать, нужно сначала энное количество времени убить на изучение этого всего. Без знакомства с деталями нельзя ответить «да» или «нет». Точнее, можно, но смысла в ответе нет — он ничего общего с реальностью не имеет.

что проще самому всё сделать

А тут вообще альтернатив нет. Делать всё равно придётся мне.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Ага, и это мне говорит человек, скативший обсуждение в «УМВР»

И это мне говорит человек, начавший обсуждение с «ваши советы говно и не работают». Работают, что и было продемонстрировано.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

01:11:14 01:11:25

Это у тебя сеть реально 11 секунд поднимается? Я таки осилил networkd, но онлайна он по каким-то причинам ждёт аж полторы минуты.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Это у тебя сеть реально 11 секунд поднимается?

Да. Я бы даже сказал, что это дофига. Хотел списать на вайфай, но на подкроватном сервере картина примерно такая же:

$ journalctl -b -u systemd-networkd
-- Logs begin at Mon 2019-04-01 12:26:57 MSK, end at Wed 2019-04-03 14:05:05 MSK. --
апр 03 01:50:26 stratofortress systemd[1]: Starting Network Service...
апр 03 01:50:26 stratofortress systemd-networkd[361]: Enumeration completed
апр 03 01:50:26 stratofortress systemd[1]: Started Network Service.
апр 03 01:50:26 stratofortress systemd-networkd[361]: eth0: Interface name change detected, eth0 has been renamed to enp4s0.
апр 03 01:50:27 stratofortress systemd-networkd[361]: enp4s0: Could not bring up interface: Invalid argument
апр 03 01:50:27 stratofortress systemd-networkd[361]: wlan0: Interface name change detected, wlan0 has been renamed to wlp2s0.
апр 03 01:50:29 stratofortress systemd-networkd[361]: enp4s0: Gained carrier
апр 03 01:50:29 stratofortress systemd-networkd[361]: enp4s0: DHCPv4 address 10.196.254.2/24 via 10.196.254.1
апр 03 01:50:31 stratofortress systemd-networkd[361]: enp4s0: Gained IPv6LL
апр 03 01:50:32 stratofortress systemd-networkd[361]: enp4s0: DHCPv6 address fd68:fd4b:10b3::2/128 timeout preferred -1 valid -1
апр 03 01:50:32 stratofortress systemd-networkd[361]: enp4s0: DHCPv6 address 2a02:2168:8380:e100::2/128 timeout preferred 1236 valid 1236
апр 03 01:50:34 stratofortress systemd-networkd[361]: enp4s0: Configured
<...>

Видимо, придётся списать на OpenWRT.

Я таки осилил networkd, но онлайна он по каким-то причинам ждёт аж полторы минуты.

O_O

Вопрос: зачем ты так прицепился к этому networkd? Оно для серверов и контейнеров. Мы же сейчас про твой десктоп говорим?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Мы же сейчас про твой десктоп говорим?

Неа. Я с виртуалкой данные шарю через 9p. Соответственно, монтирую внутри виртуалки «сетевую» ФС.

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)
Ответ на: комментарий от i-rinat

9p

Ну ты понял.

Соответственно, монтирую внутри виртуалки «сетевую» ФС.

Тогда опиши ещё раз, кто у тебя кому сеть раздаёт, а то я запутался.

Может быть, дело в том, что systemd не знает про 9p и не срабатывает автомагия, которая дописывает ко всем сетевым ФС зависимость от n-o.t?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Ну ты понял.

Нет, не понял.

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

Хост шарит файлы по 9p с помощью diod. В виртуалке шара монтируется.

Может быть, дело в том, что systemd не знает про 9p и не срабатывает автомагия, которая дописывает ко всем сетевым ФС зависимость от n-o.t?

У systemd действительно 9p не считается за сетевую ФС, но это решается дописыванием нужных зависимостей вручную.

Проблема там похоже не в зависимостях, там сам этот бинарник /lib/systemd/systemd-networkd-wait-online повисает на epoll_wait. Костылится заданием таймаута.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Нет, не понял.

9p

смайлик с ещё более выпученными глазами

У systemd действительно 9p не считается за сетевую ФС, но это решается дописыванием нужных зависимостей вручную.

Проблема там похоже не в зависимостях

Ну да, я здесь говорил про твою исходную проблему с монтированием. Почему у тебя networkd ждёт онлайна полторы минуты — отдельный вопрос.

там сам этот бинарник /lib/systemd/systemd-networkd-wait-online повисает на epoll_wait. Костылится заданием таймаута.

Ну что значит «повисает»? Это его задача — висеть, пока не придёт нотификация от networkd :)

Покажи вывод networkctl или лог networkd? Мб у тебя там какой-то интерфейс висит в «configuring».

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

смайлик с ещё более выпученными глазами

9p используется, чтобы пробрасывать папки внутрь виртуалок в qemu-kvm/libvirt/virt-manager. Там даже вроде как родная поддержка есть. Правда, я всё равно использую сторонний сервер, потому что в нём можно принудительно менять владельца файлов.

Мб у тебя там какой-то интерфейс висит в «configuring»

Да, оказалось, что так и есть.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

9p используется, чтобы пробрасывать папки внутрь виртуалок в qemu-kvm/libvirt/virt-manager

«Сетевая ФС используется для проброса файлов через сеть», спасибо, кэп. Но почему именно 9p?

Да, оказалось, что так и есть.

Это понятно, как чинить?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Это понятно, как чинить?

Да. Выбрасыванием systemd-networkd.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

9p

Поддержу intelfx, Зачем? Не в смысле ее назначения при рождении, а зачем вы вообще это пользуете?

anc ★★★★★
()
Ответ на: комментарий от anc

зачем

Первая подходящая. Мне нужно, чтобы на сервере uid и gid файлов были определённые, вне зависимости от того, как их создаст клиент подключения. У diod (сервер 9p) такая фича — встроенная.

Правда, там всё равно нет всех хотелок. И похоже, их нет вообще ни в одной сетевой ФС. Никому не нужен writeback кеш, похоже. Кеширование есть через fscache, но с ним изменения на сервере не влияют на закешированные данные на клиенте, что чрезвычайно неудобно.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Мне нужно, чтобы на сервере uid и gid файлов были определённые, вне зависимости от того, как их создаст клиент подключения.

nfs, samba ? Или я что-то не понял?

anc ★★★★★
()
Ответ на: комментарий от anc

Не знаю, не вникал. Беглый поиск показал, что в сервере 9p это есть.

i-rinat ★★★★★
()
Последнее исправление: i-rinat (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.