Dotaz: non-root LV obcas neni aktivni po rebootu VM

[MP]

Cau,

na Debian 10-12 se trapim s jednim problemem. Na Proxmox VM pouzivam vsude LVM ve stylu:

vgX-root

vgX-swap

vgY-data

V hromade stovek VM mi po vetsinou pri aktualizacich vypadne alespon jedna nahodna VM, ktera po rebootu nema aktivni vgY-data. System tedy pri pokusu mountovat danou LV via /etc/fstab spadne do initramfs prikazove radky. Staci reset VM a nabehne to. Nesetkal se nekdo s timto problemem a jak ho vyresil nakonec?

Diky.

Odpovědi

[X]

V hromade stovek VM mi po vetsinou pri aktualizacich vypadne alespon jedna nahodna VM, ktera po rebootu nema aktivni vgY-data.

Duvod? Jak jsi to diagnostikoval? Nebo to ma byt nejaka hadanka?

[MP]

Příloha:

• Screenshot from 2024-02-14 10-14-20.png (100644 bytů)

Jak mam debugovat tohle?

[X]

Jednoduse, staci si to precist. Mas tam jasne napsane v cem je problem a jak to akutne resit. Z dlouhodobeho hlediska, viz Jenda, bych se podival jak mas resene uloziste co nikdo nevi ie. zelezo, disky, pole etc.

[MP]

Vazne nevim, jak debugovat neco, cemu nestaci defaultni 90s timeout, navic kdyz je to lokalni 10GB lv nad hw raidem. A zvlast, kdyz si to vybere nahodnou VM na nahodnem pve. V patek jsem aktualizoval s restartem ~50 VM, v utery ~150 VM, tentokrat zadne nespadlo na podobne veci (VM jsou na nfs i lokalnich lvm), a znicehonic to spadne na jedne zalohovaci masine. Po resetu VM to samozrejme nabehne okamzite.

[X]

V logach toho Proxmoxu, pole, lvm neni v tom case absolutne vubec nic?

[MP]

Nic jsem zatim nenasel. Ten restart VM je pouze interni, tzn. restartuje se v ramci VM, ne v ramci pve (nezmeni se tedy ani PID). Takze ten virtualni disk je stale pripojeny k VM. Protoze tentokrat timeout byl rovnou root disk, tak neni nic v syslogu VM. Ani nevim, ze by pve logoval vnitrni stav bootovani VM.

[Jendа]

Populární je, že když bootuje virtualizační cluster, všichni se perou o storage, ještě pouští po dlouhé době fsck, který opravuje naakumulované chyby, věci se zpomalí a vytimeoutují. Ale tohle mi přijde divné:

System tedy pri pokusu mountovat danou LV via /etc/fstab spadne do initramfs prikazove radky.

Když čteš fstab a mountuješ podle něj, tak už jsi z initramfs venku. Není to systemd emergency shell už v „normálním“ systému? Pak bych zkusil zvýšit timeouty (do fstabu x-systemd.device-timeout=900, případně ještě nofail).

[k3dAR]

trochu to ma zamotane dotaz je na "non-root" lv, ktere se mountuje dle /etc/fstab, ale na screenshotu se mu nepripoji "root" lv, takze se necetlo /etc/fstab, ale opravdu to spadlo do initramfs :)

[MP]

Je to tak, trochu jsem si neuvedomele pomotal, kdy to mountuje /etc/fstab a kdy je to initramfs. Cekam, az se mi stane ten pripad s non-root LVM a zatim prisel pripad s tim, ze padnul rovnou root.

[Max]

A byl by fstab a grub.cfg z jedné z těch mašin, co ti to udělaly?
Zdar Max

[MP]

Příloha:

• grub.cfg (9411 bytů)

Zde z masiny, co padl posledne ten root, aktualizovany Debian 12.

/etc/fstab:

/dev/mapper/vg0-root /               ext4    errors=remount-ro 0       1
/dev/mapper/vg0-swap none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/mapper/vg1-barman /mnt/storage/barman ext4 errors=remount-ro 0 0

[Aleš Kapica]

Svoji roli může hrát čas. Pokud toho máš hodně, tak mohou sehrát svoji roli timeouty, jak psal Jenda. Než se ti to všechno poskládá..

To byl mimochodem důvod proč jsem už před mnoha lety řešení, jaké používá Proxmox, opustil. Hrál jsem si clusterem zhruba ve stejné době, kdy se objevil Proxmox – pozůstatkem je můj manuál pro Pacemaker. A to co nabízel Citrix je v zásadě stejné řešení, které se lišilo jen v detailech a hypervizoru.

Základem infrastruktury kterou používám, je agent, normální shellový skript, který jsem si původně napsal pro Pacemaker. Ale opruzy spojené s aktualizacemi, mne dohnaly k tomu, že jsem to vyřešil jinak. Je to všechno mnohem jednodušší, žádné extra aplikace alá libvirt s bambilionem zbytečných závislostí, kde už se jen prase vyzná v tom, co to vlastně dělá. A tak mám už 8 let klid. Ale to by bylo pro většinu zdejších remcalů nezajímavé, protože to nemá žádné UI. A přestože je konfigurace stupidně prostá, možnost chyby při konfiguraci nového stroje existuje. Sice to není nic fatálního, ale kdo neví co dělá by z toho byl zmaten a o blbé pindy nestojím.

[MP]

Příloha:

• Screenshot 2024-03-13 124512.png (137024 bytů)

Zde je screen, kdy padne non-root lv

[Aleš Kapica]

To je jenom zpráva, že skončil timeout. Ten zbytek už jsou jen závislosti. Měl by ses zaměřit na bloková zařízení ve skupině vg1.

[X]

Nebude to ten nahodny fsck nad vg0(videt nahore), ktery nestihne dobehnout pred fs-local.mount ktery na nej nepocka?

[Max]

Podle mně nejlepší tip.
Zdar Max

[X]

touch /forcefsck && reboot;

[Peter Golis]

Zaujímalo by ma na koľko štartov je nastavený interval between checks pre ten FS, a ako často sa tie stroje rebootujú. I keď v tomto prípade by som zvýšil timeout pre čakanie na disk keďže pri štarte je na diskovom poli asi dosť vysoké I/O, a prebehnúť kvantá veľkých diskov nebude len tak.

A tak isto mi udrelo do očí niečo s WiFi kartou (regulatory.db). Čo sú t za virtuálky keď majú WiFi?

[MP]

Konfigurace fstab jsem daval vyse, je identicka. Takze ten interval bude default v debianu 10-12 (do debian 9 jsem s tim problem nemel). Stroje se restartuji pokud je nove jadro, takze vetsinou to byva 1x mesicne, restartuje se to davkove po 10 strojich. Na I/O bych to moc nesazel, bezi to nad nvme. Zkusim odpozorovat, zda se to dela jen na tom konkretnim diskovem poli, kde jsou databazove VM, protoze na dalsich polich mame spis nedatabazove (tzn. je tam velmi malo VM, ktere maji extra vg1 pro data).

Co se tyce cekani na disk, tak tam by mel byt defaultni systemd timeout 90s?

Co se tyce wifi, na tech VM nikdy wifi nebyla a ani nebude, ani na tom zeleze. Zrejme je to primo v distribucnim jadru.

[Aleš Kapica]

Šmarjá, jste snad slepí?! Tp, že se v logu objevují na přeskáčku různé zprávy souvisí s paralelizací procesů při spouštění. Některé doběhnou dřív, jiné později. A v tom je také zakopaný pes. To u čeho je DEPEND se nevykoná protože selže to na čem to závisí. A tím je sestavení LVM skupiny vg1, kde tím pádem nevznikne LV oddíl postgresql, takže není co namountovat.

Já už LVM nepoužívám, ale v manuálu, který jsem si k LVM sepsal k tomu něco je. Každému doporučuji, ať si v takovém případě vezme tužku a papír, aby si udělal jasno co kde je, co se kam mountuje, z čeho je to sestavené, atp.

[Max]

dmesg a full log ze systemd jsi si nevytahoval?
Zdar Max

[MP]

Priste, uz jsem byl v casovem skluzu a ted toho mam dost.

[Peter Golis]

Zobrať si logy je snáď základ pri riešení pretrvávajúceho problému.

Teda ak sa k tomu človek nepostaví tak, že reboot je finálne riešenie. To by stačil watchdog.