Ожидание завершения работы при использовании сетевых шар

sleepycat	# 9 лет, 11 месяцев назад
Темы: 98 Сообщения: 3291 Участник с: 19 июля 2011	Наконец-то нашел решение(точнее сказать наконецто дошли руки), которое как обычно валялось под ногами. Как я уже писал, при использовании сетевых шар, точнее сказать после их монтирования(без последуюшего отмонтирования руками) , система долго уходила в выключение(стопорилась гдето в районе umount.target), решил проблему, добавив параметр таймаут в директивы юнита. Например: cat /etc/systemd/system/mnt-music.mount Description=Mount remote smb-share on predator server(Music) Before=umount.target After=predator-remote-fs.target Conflicts=umount.target What=//10.10.10.50/music Where=/mnt/music Type=cifs Options=credentials=/home/jinn/.smb/key,rw,users,noauto TimeoutSec=3s WantedBy=predator-remote-fs.target По умолчанию 90 секунд ;) Может кому поможет. PS При использовании fstab, а не юнита, тоже можно задать через x-systemd.device-timeout= Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

# 9 лет, 11 месяцев назад

Сообщения: 3291

Участник с: 19 июля 2011

Наконец-то нашел решение(точнее сказать наконецто дошли руки), которое как обычно валялось под ногами. Как я уже писал, при использовании сетевых шар, точнее сказать после их монтирования(без последуюшего отмонтирования руками) , система долго уходила в выключение(стопорилась гдето в районе umount.target), решил проблему, добавив параметр таймаут в директивы юнита. Например:

cat /etc/systemd/system/mnt-music.mount

Description=Mount remote smb-share on predator server(Music)
Before=umount.target
After=predator-remote-fs.target
Conflicts=umount.target

What=//10.10.10.50/music
Where=/mnt/music
Type=cifs
Options=credentials=/home/jinn/.smb/key,rw,users,noauto
TimeoutSec=3s

WantedBy=predator-remote-fs.target

По умолчанию 90 секунд ;)
Может кому поможет.
PS
При использовании fstab, а не юнита, тоже можно задать через x-systemd.device-timeout=

Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

Natrio	# 9 лет, 11 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	А что, с fstab такое не проявляется? У меня примонтированы на одной машине две самбы, на другой NFS, и ничего при выключении не тормозит, однако.

anthonio	# 9 лет, 11 месяцев назад
Темы: 18 Сообщения: 378 Участник с: 11 августа 2009	У меня через autofs монтирование. Такая же фигня. Сначала убивается autofs, потом network.target а в самом конце начинает папки отмонтировывать.чудо в перьях. 120 секунд ждём ответа от сервера…. когда уже network.target давно остановлен.

Natrio	# 9 лет, 11 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	anthonio У меня через autofs монтирование. Такая же фигня. Сначала убивается autofs, потом network.target а в самом конце начинает папки отмонтировывать.чудо в перьях. 120 секунд ждём ответа от сервера…. когда уже network.target давно остановлен. Ой, autofs это очень скользкая штука. Монтирование по факту обращения часто срабатывает в самых неподходящих случаях, особенно с программами, которые любят без спроса шарить по ФС, не учитывая последствий в виде неожиданного монтирования, или его длительных и безуспешных попыток.

Natrio

# 9 лет, 11 месяцев назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

anthonio
У меня через autofs монтирование. Такая же фигня. Сначала убивается autofs, потом network.target а в самом конце начинает папки отмонтировывать.чудо в перьях.
120 секунд ждём ответа от сервера…. когда уже network.target давно остановлен.

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

sleepycat	# 9 лет, 11 месяцев назад
Темы: 98 Сообщения: 3291 Участник с: 19 июля 2011	подтверждаю, в моем случае как раз autofs так сказать via systemd )) , тобишь через .automount . Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

sleepycat

# 9 лет, 11 месяцев назад

Темы: 98

Сообщения: 3291

Участник с: 19 июля 2011

подтверждаю, в моем случае как раз autofs так сказать via systemd )) , тобишь через .automount .

Garry_Topor_	# 5 лет назад (отредактировано 5 лет назад)
Темы: 2 Сообщения: 9 Участник с: 28 июня 2017	у меня та же проблема, сетевые папки автоматически не отмонтируются нормально, а вариант ТС это конечно костыль, потому что процесс нормально не закрывается, висит, но через 3 секунды его обрывают. Это не есть гут. Я бы с удовольствием услышал нормальное решение проблемы. Через systemd - mount и automount такая же ботва - процесс висит. Через fstab процесс закрытия висит, потом завершается из-за каунтдауна, ну ошибок не пишет, дальше обычная перезагрузка, но явно что-то не то, процесс должен сам автоматически без проблем завершаться...

Garry_Topor_

# 5 лет назад (отредактировано 5 лет назад)

Темы: 2

Сообщения: 9

Участник с: 28 июня 2017

у меня та же проблема, сетевые папки автоматически не отмонтируются нормально, а вариант ТС это конечно костыль, потому что процесс нормально не закрывается, висит, но через 3 секунды его обрывают. Это не есть гут. Я бы с удовольствием услышал нормальное решение проблемы. Через systemd - mount и automount такая же ботва - процесс висит. Через fstab процесс закрытия висит, потом завершается из-за каунтдауна, ну ошибок не пишет, дальше обычная перезагрузка, но явно что-то не то, процесс должен сам автоматически без проблем завершаться...