Bug 35150

Отладка показала, что udev запускает следующую команду:

  lvm pvscan -v --background --cache --activate ay --major 8 --minor 0

Делает он это по правилу из файла /lib/udev/rules.d/69-dm-lvm-metad.rules, в самом конце.

При этом pvscan пытается общаться с lvmetad через /run/lvm/lvmetad.socket (да, я впихнул в правило strace). lvm2-lvmetad в нашем systemd поидее должен socket-актирвироваться, однако этого не происходит до тех пор, пока с systemd-udev-settle не случится timeout, и загрузка не пойдёт дальше.

В том же файлике /lib/udev/rules.d/69-dm-lvm-metad.rules обнаружился следующий абзац:

# The method for invoking pvscan is selected at build time with the option
# --(enable|disable)-udev-systemd-background-jobs to "configure".
# On modern distributions with recent systemd, it's "systemd_background";
# on others, "direct_pvscan".
GOTO="direct_pvscan"

Я предположил, что Сизиф с systemd это вполне modern distribution, и закомментировал этот GOTO. И действительно, это решило проблему: загрузка системы теперь происходит быстро, все разделы на LVM видны и монтируются согласно тому, что я написал в /etc/fstab.

Видимо, с современным systemd --enable-udev-systemd-background-jobs не просто желателен, а необходим. С другой стороны, если нужно тот же udev использовать на системах с SysV init, наверное, часть этой логики надо перетаскивать из build time в runtime...

Если что, я готов что-нибудь потестировать =)

Я столкнулся с той же проблемой после обновления до сизифа и решил её довольно криво, но быстро - я отключил ожидание:
sudo systemctl mask systemd-udev-settle

Аналогично, готов потестировать, как только в сизифе появится новый udev-rules.

(В ответ на комментарий №2)
> В том же файлике /lib/udev/rules.d/69-dm-lvm-metad.rules обнаружился следующий
> абзац:
> 
> # The method for invoking pvscan is selected at build time with the option
> # --(enable|disable)-udev-systemd-background-jobs to "configure".
> # On modern distributions with recent systemd, it's "systemd_background";
> # on others, "direct_pvscan".
> GOTO="direct_pvscan"
> 
> Я предположил, что Сизиф с systemd это вполне modern distribution, и
> закомментировал этот GOTO. И действительно, это решило проблему: загрузка
> системы теперь происходит быстро, все разделы на LVM видны и монтируются
> согласно тому, что я написал в /etc/fstab.
> 
> Видимо, с современным systemd --enable-udev-systemd-background-jobs не просто
> желателен, а необходим. С другой стороны, если нужно тот же udev использовать
> на системах с SysV init, наверное, часть этой логики надо перетаскивать из
> build time в runtime...
> 
> Если что, я готов что-нибудь потестировать =)

А можно протестировать эти же ваши действия под SysV?
У меня есть подозрение, что будет все нормально работать.

и для информации, в master ветке lvm2 выпиливают lvmetad как ненужную сущность.

(In reply to comment #4)
> А можно протестировать эти же ваши действия под SysV?
> У меня есть подозрение, что будет все нормально работать.

Попробую в понедельник.

В багзилле RedHat есть длительные обсуждения очень похожей проблемы, которые закончились у них не пойми чем
https://bugzilla.redhat.com/show_bug.cgi?id=989607
https://bugzilla.redhat.com/show_bug.cgi?id=1023250

но там назван способ обхода:
global/use_lvmetad = 0 in /etc/lvm/lvm.conf 

мне отлично помогло на p8, а до того было длительное ожидание, которое приводило к emergency mode (с предложением нажать Ctrl-D).

(В ответ на комментарий №2)
> В том же файлике /lib/udev/rules.d/69-dm-lvm-metad.rules обнаружился следующий
> абзац:
> 
> # The method for invoking pvscan is selected at build time with the option
> # --(enable|disable)-udev-systemd-background-jobs to "configure".
> # On modern distributions with recent systemd, it's "systemd_background";
> # on others, "direct_pvscan".
> GOTO="direct_pvscan"
> 
> Я предположил, что Сизиф с systemd это вполне modern distribution, и
> закомментировал этот GOTO. И действительно, это решило проблему: загрузка
> системы теперь происходит быстро, все разделы на LVM видны и монтируются
> согласно тому, что я написал в /etc/fstab.
> 
> Видимо, с современным systemd --enable-udev-systemd-background-jobs не просто
> желателен, а необходим. С другой стороны, если нужно тот же udev использовать
> на системах с SysV init, наверное, часть этой логики надо перетаскивать из
> build time в runtime...
> 
> Если что, я готов что-нибудь потестировать =)

lvm2 собирается с --disable-udev-systemd-background-jobs, поэтому в rules попадает GOTO="direct_pvscan".
А собирается он с этим параметром потому, что в rules запускается systemd-run.
Надо тогда systemd-run перенести в /bin.

А можно еще попросить, убедиться что lvm2-lvmetad.socket включен, и если нет  сделать:
systemctl enable lvm2-lvmetad.socket
и перезагрузиться.

(In reply to comment #9)
> А можно еще попросить, убедиться что lvm2-lvmetad.socket включен, и если нет 
> сделать:
> systemctl enable lvm2-lvmetad.socket
> и перезагрузиться.

lvm2-lvmetad.socket был включен когда я это поймал.

Сейчас перепроверил:
- обновился до сегодняшнего Сизифа
- apt-get install --reinstall lvm2
- перезагрузился

udev-settle не сумел завершиться и меня выбросило в recovery mode. В этом самом recovery mode я вернул назад комментарий в 88 строку /lib/udev/rules.d/69-dm-lvm-metad.rules:

# GOTO="direct_pvscan"

и нормально загрузился, быстро и все разделы на месте.

(In reply to comment #7)
> В багзилле RedHat есть длительные обсуждения очень похожей проблемы, которые
> закончились у них не пойми чем
> https://bugzilla.redhat.com/show_bug.cgi?id=989607
> https://bugzilla.redhat.com/show_bug.cgi?id=1023250
> 
> но там назван способ обхода:
> global/use_lvmetad = 0 in /etc/lvm/lvm.conf 
> 
> мне отлично помогло на p8, а до того было длительное ожидание, которое
> приводило к emergency mode (с предложением нажать Ctrl-D).

Проверил и этот вариант, естественно вернув GOTO как было в пакете. Тоже помогло. Пока оставил так.

Я сделал таск #216915, в котором по-умолчанию отключено использование lvmetad (global/use_lvmetad = 0).

Видимо пока мы пытаемся усидеть на двух стульях (systemd и sysv) придется делать выбор в пользу sysv.
В ветке master уже удалили lvmetad. Но я пока не решаюсь её собирать.

(В ответ на комментарий №13)
> Я сделал таск #216915, в котором по-умолчанию отключено использование lvmetad
> (global/use_lvmetad = 0).

посылать в таком виде в сизиф? одобряете?
 
> Видимо пока мы пытаемся усидеть на двух стульях (systemd и sysv) придется
> делать выбор в пользу sysv.
> В ветке master уже удалили lvmetad. Но я пока не решаюсь её собирать.

У меня после обновления до lvm2-2.02.182-alt2 загрузка растянулась с 15 секунд до 4-х минут с таким результатом:

=8<======================================================================
root@thinkpad ~ #systemctl --state=failed
  UNIT                          LOAD   ACTIVE SUB    DESCRIPTION                       
● lvm2-activation-early.service loaded failed failed Activation of LVM2 logical volumes
● lvm2-activation-net.service   loaded failed failed Activation of LVM2 logical volumes
● lvm2-activation.service       loaded failed failed Activation of LVM2 logical volumes

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
root@thinkpad ~ #systemctl --no-pager status lvm2-activation-early lvm2-activation-net lvm2-activation
● lvm2-activation-early.service - Activation of LVM2 logical volumes
   Loaded: loaded (/etc/lvm/lvm.conf; generated)
   Active: failed (Result: timeout) since Sat 2018-12-01 16:13:32 +07; 34min ago
     Docs: man:lvm2-activation-generator(8)
  Process: 1263 ExecStart=/sbin/lvm vgchange -aay --ignoreskippedcluster (code=exited, status=0/SUCCESS)
 Main PID: 1263 (code=exited, status=0/SUCCESS)

дек 01 16:12:01 thinkpad.evg-krsk.dyndns.org systemd[1]: Starting Activation of LVM2 logical volumes...
дек 01 16:12:01 thinkpad.evg-krsk.dyndns.org dmeventd[1299]: dmeventd ready for processing.
дек 01 16:12:01 thinkpad.evg-krsk.dyndns.org lvm[1299]: Monitoring thin pool nonredundant-thinpool.
дек 01 16:12:01 thinkpad.evg-krsk.dyndns.org lvm[1263]:   1 logical volume(s) in volume group "nonredundant" now active
дек 01 16:12:01 thinkpad.evg-krsk.dyndns.org lvm[1263]:   3 logical volume(s) in volume group "thinkpad" now active
дек 01 16:12:01 thinkpad.evg-krsk.dyndns.org lvm[1299]: dmeventd received break, scheduling exit.
дек 01 16:13:32 thinkpad.evg-krsk.dyndns.org systemd[1]: lvm2-activation-early.service: State 'stop-sigterm' timed out. Killing.
дек 01 16:13:32 thinkpad.evg-krsk.dyndns.org systemd[1]: lvm2-activation-early.service: Killing process 1299 (dmeventd) with signal SIGKILL.
дек 01 16:13:32 thinkpad.evg-krsk.dyndns.org systemd[1]: lvm2-activation-early.service: Failed with result 'timeout'.
дек 01 16:13:32 thinkpad.evg-krsk.dyndns.org systemd[1]: Failed to start Activation of LVM2 logical volumes.

● lvm2-activation-net.service - Activation of LVM2 logical volumes
   Loaded: loaded (/etc/lvm/lvm.conf; generated)
   Active: failed (Result: timeout) since Sat 2018-12-01 16:16:32 +07; 31min ago
     Docs: man:lvm2-activation-generator(8)
  Process: 1318 ExecStart=/sbin/lvm vgchange -aay --ignoreskippedcluster (code=exited, status=0/SUCCESS)
  Process: 1310 ExecStartPre=/sbin/udevadm settle (code=exited, status=0/SUCCESS)
 Main PID: 1318 (code=exited, status=0/SUCCESS)

дек 01 16:15:02 thinkpad.evg-krsk.dyndns.org systemd[1]: Starting Activation of LVM2 logical volumes...
дек 01 16:15:02 thinkpad.evg-krsk.dyndns.org dmeventd[1330]: dmeventd ready for processing.
дек 01 16:15:02 thinkpad.evg-krsk.dyndns.org lvm[1330]: Monitoring thin pool nonredundant-thinpool.
дек 01 16:15:02 thinkpad.evg-krsk.dyndns.org lvm[1318]:   1 logical volume(s) in volume group "nonredundant" now active
дек 01 16:15:02 thinkpad.evg-krsk.dyndns.org lvm[1318]:   3 logical volume(s) in volume group "thinkpad" now active
дек 01 16:15:02 thinkpad.evg-krsk.dyndns.org lvm[1330]: dmeventd received break, scheduling exit.
дек 01 16:16:32 thinkpad.evg-krsk.dyndns.org systemd[1]: lvm2-activation-net.service: State 'stop-sigterm' timed out. Killing.
дек 01 16:16:32 thinkpad.evg-krsk.dyndns.org systemd[1]: lvm2-activation-net.service: Killing process 1330 (dmeventd) with signal SIGKILL.
дек 01 16:16:32 thinkpad.evg-krsk.dyndns.org systemd[1]: lvm2-activation-net.service: Failed with result 'timeout'.
дек 01 16:16:32 thinkpad.evg-krsk.dyndns.org systemd[1]: Failed to start Activation of LVM2 logical volumes.

● lvm2-activation.service - Activation of LVM2 logical volumes
   Loaded: loaded (/etc/lvm/lvm.conf; generated)
   Active: failed (Result: timeout) since Sat 2018-12-01 16:15:02 +07; 33min ago
     Docs: man:lvm2-activation-generator(8)
  Process: 1305 ExecStart=/sbin/lvm vgchange -aay --ignoreskippedcluster (code=exited, status=0/SUCCESS)
 Main PID: 1305 (code=exited, status=0/SUCCESS)

дек 01 16:13:32 thinkpad.evg-krsk.dyndns.org systemd[1]: Starting Activation of LVM2 logical volumes...
дек 01 16:13:32 thinkpad.evg-krsk.dyndns.org dmeventd[1307]: dmeventd ready for processing.
дек 01 16:13:32 thinkpad.evg-krsk.dyndns.org lvm[1307]: Monitoring thin pool nonredundant-thinpool.
дек 01 16:13:32 thinkpad.evg-krsk.dyndns.org lvm[1305]:   1 logical volume(s) in volume group "nonredundant" now active
дек 01 16:13:32 thinkpad.evg-krsk.dyndns.org lvm[1305]:   3 logical volume(s) in volume group "thinkpad" now active
дек 01 16:13:32 thinkpad.evg-krsk.dyndns.org lvm[1307]: dmeventd received break, scheduling exit.
дек 01 16:15:02 thinkpad.evg-krsk.dyndns.org systemd[1]: lvm2-activation.service: State 'stop-sigterm' timed out. Killing.
дек 01 16:15:02 thinkpad.evg-krsk.dyndns.org systemd[1]: lvm2-activation.service: Killing process 1307 (dmeventd) with signal SIGKILL.
дек 01 16:15:02 thinkpad.evg-krsk.dyndns.org systemd[1]: lvm2-activation.service: Failed with result 'timeout'.
дек 01 16:15:02 thinkpad.evg-krsk.dyndns.org systemd[1]: Failed to start Activation of LVM2 logical volumes.
[1]    4898 exit 3     systemctl --no-pager status lvm2-activation-early lvm2-activation-net 
=8<======================================================================

восстановить скорость загрузки удалось лишь явно задав "use_lvmetad = 1" в /etc/lvm/lvm.conf.

У меня на 2 ~ одинаковых рабочих станциях с lvm и lvmetad  поведение с точностью до наоборот. При том что "разбивка" дисков примерно одинаковая.

на домашней,если включаю use_lvmetad = 1 - то загрузка минут 4-5. Без ~2 минуты.
на рабочей с точностью до наоборот.

Единственное что бросается в глаз - на домашней станции пустой /etc/lvm/cache
На рабочей  совсем не пустой и lvm и стартует почти моментально.

P8.

Собственно с рабочей:

2.893s systemd-udev-settle.service
2.198s dev-mapper-MAIN\x2dROOTFS.device

С домашней:
120.539s systemd-udev-settle.service
9.474s dev-mapper-SYSLVM\x2dROOTFS.device

Проявляются ли у вас проблемы с lvm сейчас?
Я в rules давным-давно добавил авто-детект как запускать. Все должно было исправится.