[Comm] network filesystems and systemd

[Comm] network filesystems and systemd

[Michael A. Kangin]

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

У меня на P7 почему/то cifs/nfs файловые системы пытаются смонтироваться
задолго до готовности сети (она с ручными настройками и долго
инициализируется).
А потом уже и не пытаются. Как бы попросить их монтироваться как можно
позже?

-- 
wbr, Michael A. Kangin

Re: [Comm] network filesystems and systemd

[Mikhail Efremov]

On Sun, 18 Aug 2013 17:26:39 +0400 Michael A. Kangin wrote:
> Здравствуйте.
> 
> У меня на P7 почему/то cifs/nfs файловые системы пытаются смонтироваться
> задолго до готовности сети (она с ручными настройками и долго
> инициализируется).
> А потом уже и не пытаются. Как бы попросить их монтироваться как можно
> позже?

Они должны монтироваться не "как можно позже", а после network.target и
network-online.target. Если эти фс прописаны в fstab, то для них
автоматически генерятся *.mount файлы (можно их поискать в выводе
systemctl list-units -t mount). Можно написать и свой mount-файл, хотя
автогенеренные должны быть вполне рабочими, в них как раз стоит
After=network.target
After=network-online.target
Надо разбираться почему это не работает, network.target достигается
только после того, как отработает network.service. Т.е. при
использовании etcnet все должно работать правильно.
Если же используется NM, то нужно включить
NetworkManager-wait-online.service.

-- 
WBR, Mikhail Efremov

Re: [Comm] network filesystems and systemd

[Michael A. Kangin]

19.08.2013 17:30, Mikhail Efremov пишет:

> Они должны монтироваться не "как можно позже", а после network.target и
> network-online.target. 
...
> Надо разбираться почему это не работает, network.target достигается
> только после того, как отработает network.service. Т.е. при
> использовании etcnet все должно работать правильно.
> Если же используется NM, то нужно включить
> NetworkManager-wait-online.service.
> 

У меня с моим сочетанием сетевуха-свитч-бриджики есть такая особенность
- может очень долго инициализироваться сеть. Если я пытаюсь получить
адрес по DHCP, то эти network.service, или
NetworkManager-wait-online.service, могут просто тупо отваливаться по
таймауту.

Сейчас адрес прописан статически и сеть "поднимается" какбы мгновенно.
Но до реальной работоспособности еще должно пройти много времени.
а тут события несутся стремительно, и в какой-то не той последовательности:

Aug 19 10:00:25  systemd[1]: Starting Network is Online.
Aug 19 10:00:25  systemd[1]: Reached target Network is Online.
...
сеть сделала вид что сразу готова, и сразу же кидаемся монтировать
сетевые системы
Aug 19 10:00:25  systemd[1]: Mounting /mnt/admins...
Aug 19 10:00:25  systemd[1]: Mounting /mnt/server...
Aug 19 10:00:25  systemd[1]: Mounting /mnt/public...
Aug 19 10:00:25  systemd[1]: Mounting /mnt/backups...
...
и обламываемся потому что ДНС недоступно (используется локальный)
Aug 19 10:00:25  mount[818]: mount error: could not resolve address for
server: Unknown error
Aug 19 10:00:25  mount[822]: mount error: could not resolve address for
server: Unknown error
Aug 19 10:00:25  mount[826]: mount.nfs: Failed to resolve server
storage: Name or service not known
Aug 19 10:00:25  mount[829]: mount.nfs: Failed to resolve server
storage: Name or service not known
...
Aug 19 10:00:25  systemd[1]: mnt-admins.mount mount process exited,
code=exited status=1
Aug 19 10:00:25  systemd[1]: Failed to mount /mnt/admins.
Aug 19 10:00:25  systemd[1]: Dependency failed for Remote File Systems.
Aug 19 10:00:25  systemd[1]: Unit mnt-admins.mount entered failed state
...
а вот и сеть начала действительно подниматься
Aug 19 10:00:25  kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
Aug 19 10:00:25  kernel: r8169 0000:03:00.0: irq 45 for MSI/MSI-X
Aug 19 10:00:25  kernel: r8169 0000:03:00.0 eth0: RTL8168f/8111f at
0xffffc90005bc8000, 10:bf:48:83:90:94, XID 08000800 IRQ
Aug 19 10:00:25  kernel: r8169 0000:03:00.0 eth0: jumbo features
[frames: 9200 bytes, tx checksumming: ko]
...
А вот и наконец поднялся локальный ДНС. Впрочем, без сети он всё равно
половину неотрезолвит
Aug 19 10:00:27  named[1272]: starting BIND 9.9.2-P2
Aug 19 10:00:27  named[1272]: using 1 UDP listener per interface
Aug 19 10:00:27  named[1272]: using up to 4096 sockets
....
А вот etcnet добрался до интерфейсов
Aug 19 10:00:29  network[3497]: 4 interfaces found
Aug 19 10:00:29  network[3497]: Starting group 0/virtual (1 interfaces)
Aug 19 10:00:29  network[3497]: Starting lo:  'lo' is already up SKIPPED
Aug 19 10:00:29  network[3497]: Starting group 1/realphys (1 interfaces)
Aug 19 10:00:29  kernel: Ebtables v2.0 registered
Aug 19 10:00:29  kernel: r8169 0000:03:00.0 eth0: link down
Aug 19 10:00:29  kernel: r8169 0000:03:00.0 eth0: link down
Aug 19 10:00:29  kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Aug 19 10:00:29  kernel: ip6_tables: (C) 2000-2006 Netfilter Core Team
Aug 19 10:00:29  network[3497]: Starting eth0: ....OK
Aug 19 10:00:30  kernel: device eth0 entered promiscuous mode
Aug 19 10:00:30  kernel: IPv6: ADDRCONF(NETDEV_UP): br-eth0: link is not
ready
Aug 19 10:00:30  network[3497]: Starting br-eth0: ........OK
Aug 19 10:00:30  kernel: IPv6: ADDRCONF(NETDEV_UP): br-eth0.2: link is
not ready
Aug 19 10:00:30  network[3497]: Starting br-eth0.2: ....OK
....
А вот поднялся наконец линк на сетевом интерфейсе. Это еще быстро.
Aug 19 10:00:32  kernel: r8169 0000:03:00.0 eth0: link up
Aug 19 10:00:32  kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link
becomes ready
Aug 19 10:00:32  kernel: br-eth0: port 1(eth0) entered forwarding state
Aug 19 10:00:32  kernel: br-eth0: port 1(eth0) entered forwarding state
Aug 19 10:00:32  kernel: IPv6: ADDRCONF(NETDEV_CHANGE): br-eth0: link
becomes ready
Aug 19 10:00:32  kernel: IPv6: ADDRCONF(NETDEV_CHANGE): br-eth0.2: link
becomes ready
...
И бридж прочухался. Сейчас бы к этому времени DHCP уже давно послал бы
несколько запросов с увеличивающимся интервалом.
Вот тут бы и надо всё монтировать.
Aug 19 10:00:47  kernel: br-eth0: port 1(eth0) entered forwarding state
...
Первая сетевая активность
Aug 19 10:01:00  prefdm[1638]: [+32.75s] DEBUG: Got
Query(authentication_names=[])
Aug 19 10:01:01  prefdm[1638]: [+33.59s] DEBUG: Connecting to XServer
192.168.0.149:7



-- 
wbr, Michael A. Kangin

Re: [Comm] network filesystems and systemd

[Mikhail Efremov]

On Mon, 19 Aug 2013 21:00:40 +0400 Michael A. Kangin wrote:
> 19.08.2013 17:30, Mikhail Efremov пишет:
> 
> > Они должны монтироваться не "как можно позже", а после network.target и
> > network-online.target. 
> ...
> > Надо разбираться почему это не работает, network.target достигается
> > только после того, как отработает network.service. Т.е. при
> > использовании etcnet все должно работать правильно.
> > Если же используется NM, то нужно включить
> > NetworkManager-wait-online.service.
> > 
> 
> У меня с моим сочетанием сетевуха-свитч-бриджики есть такая особенность
> - может очень долго инициализироваться сеть. Если я пытаюсь получить
> адрес по DHCP, то эти network.service, или
> NetworkManager-wait-online.service, могут просто тупо отваливаться по
> таймауту.

В etcnet можно увеличить таймаут для dhcp-клиента. А
NetworkManager-wait-online.service можно написать свой, тоже с
увеличенным таймаутом, взяв за основу системный.

> Aug 19 10:00:25  systemd[1]: Starting Network is Online.
> Aug 19 10:00:25  systemd[1]: Reached target Network is Online.
> ...
> сеть сделала вид что сразу готова, и сразу же кидаемся монтировать
> сетевые системы

Можно написать свой my-wait-online.service, в котором будет вызываться
скрипт, ожидающий появления сети по каким-то критериям. За основу можно
взять тот же NetworkManager-wait-online.service.
Тогда загрузка затормозится до реального появления сети и дальше все
отработает правильно.

> Aug 19 10:00:25  systemd[1]: Mounting /mnt/admins...
> Aug 19 10:00:25  systemd[1]: Mounting /mnt/server...
> Aug 19 10:00:25  systemd[1]: Mounting /mnt/public...
> Aug 19 10:00:25  systemd[1]: Mounting /mnt/backups...
> ...
> и обламываемся потому что ДНС недоступно (используется локальный)

В смысле свой кэширующий на 127.0.0.1?
Тогда лучше написать в fstab ip-адрес. Иначе придется обеспечивать,
чтобы DNS-сервер был поднят к моменту достижения network.target (или
network-online.target. В принципе, можно написать и такой свой
service-файл. Или писать свой mount-файл, в котором уже написать нужные
зависимости.

> Aug 19 10:00:25  mount[818]: mount error: could not resolve address for
> server: Unknown error
> Aug 19 10:00:25  mount[822]: mount error: could not resolve address for
> server: Unknown error
> Aug 19 10:00:25  mount[826]: mount.nfs: Failed to resolve server
> storage: Name or service not known
> Aug 19 10:00:25  mount[829]: mount.nfs: Failed to resolve server
> storage: Name or service not known
> ...
> Aug 19 10:00:25  systemd[1]: mnt-admins.mount mount process exited,
> code=exited status=1
> Aug 19 10:00:25  systemd[1]: Failed to mount /mnt/admins.
> Aug 19 10:00:25  systemd[1]: Dependency failed for Remote File Systems.
> Aug 19 10:00:25  systemd[1]: Unit mnt-admins.mount entered failed state
> ...
> Aug 19 10:00:27  named[1272]: starting BIND 9.9.2-P2
> Aug 19 10:00:27  named[1272]: using 1 UDP listener per interface
> Aug 19 10:00:27  named[1272]: using up to 4096 sockets
> ....
> А вот etcnet добрался до интерфейсов
> Aug 19 10:00:29  network[3497]: 4 interfaces found

Вот это странно, монтирование сетевых fs должно быть уже после
network.target, который не должен быть достигнут пока не закончит
работу network.service. Попробую воспроизвести.

-- 
WBR, Mikhail Efremov

Re: [Comm] network filesystems and systemd

[Michael A. Kangin]

19.08.2013 21:36, Mikhail Efremov пишет:

> Можно написать свой my-wait-online.service, в котором будет вызываться
> скрипт, ожидающий появления сети по каким-то критериям. За основу можно
> взять тот же NetworkManager-wait-online.service.
> Тогда загрузка затормозится до реального появления сети и дальше все
> отработает правильно.

Да, наверное это проще всего будет. Хоть и как-то несистемненько.

>> А вот etcnet добрался до интерфейсов
>> Aug 19 10:00:29  network[3497]: 4 interfaces found
> 
> Вот это странно, монтирование сетевых fs должно быть уже после
> network.target, который не должен быть достигнут пока не закончит
> работу network.service. Попробую воспроизвести.

Не исключено, это мой локальный ужас-ужас.
Когда я поставил эту систему на p7, и она вообще висла при старте из-за
сети, я, не слишком хорошо зная systemd, мог не очень корректно
заставить её хоть как-то работать.
Помнится, принудительно отключал всякие networkmanagerы-wait-online,
прописывал адреса ручками, возможно что-нибудь снёс ненароком.



-- 
wbr, Michael A. Kangin

Re: [Comm] network filesystems and systemd

[Michael A. Kangin]

19.08.2013 17:30, Mikhail Efremov пишет:

> network-online.target. Если эти фс прописаны в fstab, то для них
> автоматически генерятся *.mount файлы (можно их поискать в выводе
> systemctl list-units -t mount). Можно написать и свой mount-файл, хотя
> автогенеренные должны быть вполне рабочими, в них как раз стоит

Кстати, systemd перечисляет такие .mount-юниты, но реально этих файлов
нигде на диске нету.

mnt-admins.mount             loaded active mounted /mnt/admins
mnt-backups.mount            loaded failed failed  /mnt/backups
mnt-public.mount             loaded failed failed  /mnt/public
mnt-server.mount             loaded failed failed  /mnt/server






-- 
wbr, Michael A. Kangin

Re: [Comm] network filesystems and systemd

[Mikhail Efremov]

On Mon, 19 Aug 2013 21:46:13 +0400 Michael A. Kangin wrote:
> 19.08.2013 17:30, Mikhail Efremov пишет:
> 
> > network-online.target. Если эти фс прописаны в fstab, то для них
> > автоматически генерятся *.mount файлы (можно их поискать в выводе
> > systemctl list-units -t mount). Можно написать и свой mount-файл, хотя
> > автогенеренные должны быть вполне рабочими, в них как раз стоит
> 
> Кстати, systemd перечисляет такие .mount-юниты, но реально этих файлов
> нигде на диске нету.
> 
> mnt-admins.mount             loaded active mounted /mnt/admins
> mnt-backups.mount            loaded failed failed  /mnt/backups
> mnt-public.mount             loaded failed failed  /mnt/public
> mnt-server.mount             loaded failed failed  /mnt/server

Не знаю как и где хранит их сам systemd, но можно сгенерить их заново с
помощью просто запуска 
/lib/systemd/system-generators/systemd-fstab-generator. Они будут
в /tmp.

-- 
WBR, Mikhail Efremov

Re: [Comm] network filesystems and systemd

[Stanislav Vlasov]

21 августа 2013 г., 11:02 пользователь Gleb Kulikov <glebus@asd.iao.ru> написал:

> > У меня на P7 почему/то cifs/nfs файловые системы пытаются смонтироваться
> > задолго до готовности сети (она с ручными настройками и долго

> А почему не используете autofs?

оверкилл для случая единственного каталога с единственного всегда
включенного сервера.

-- 
Stanislav

Re: [Comm] network filesystems and systemd

[Stanislav Vlasov]

21 августа 2013 г., 13:28 пользователь Gleb Kulikov <glebus@asd.iao.ru> написал:
>> > А почему не используете autofs?
>> оверкилл для случая единственного каталога с единственного всегда
>> включенного сервера.

> Не уверен. Неплохо спасает в случае, если связи до сервера нет (пропадает).

Не все ходят до nfs через три впн и девять маршрутизаторов поверх
gprs, где autofs безусловно полезнее записи в fstab.
В случае же, когда пропадание связи в течение рабочего дня менее
вероятно, чем проблемы на рабочей станции - дешевле записать в fstab и
забить.

В любом случае, независимо от качества связи, сетевые фс, монтируемые
в fstab, должны монтироваться уже после поднятия сети.

-- 
Stanislav

P.S. За ~4 года эксплуатации домашних каталогов на nfs было два или
три сбоя, связанных с недоступностью сервера в локалке. При этом как
минимум раз в месяц происходили проблемы с рабочей станцией (от "юзер
случайно пнул кнопку питания" до "остановился кулер на процессоре").