Naka-mask ang unit na -.mount: hindi magsisimula ang client ng OpenVPN

Nabibigo ang serbisyo mo bago pa man tumakbo ang OpenVPN, at ang error ay tungkol sa isang mount unit na hindi mo kailanman na-configure. Iyon ang palatandaan: tinatanggihan ng systemd ang buong transaksyon dahil naka-mask ang root mount unit, at hindi pa nababasa ang profile ng VPN mo. Ang karaniwang dahilan ay isang file na naiwan sa direktoryo ng mga runtime unit, hindi isang sirang fstab at hindi isang kulang na certificate. Unahin ang paghabol sa file, dahil iyon ang pinakamurang paliwanag na maaaring alisin.

Binanggit ng error ang root mount, hindi ang profile mo

Ang systemd mismo ang gumagawa ng root mount unit mula sa impormasyon ng mount ng kernel, at tinatawag itong -.mount dahil ang gitling ay kumakatawan sa root path. Karaniwang nasa memorya lamang ang unit na iyon at walang file sa likod nito. Kapag sinabi ng error na naka-mask ito, may naglagay ng unit file kung saan ito ikakarga ng systemd at itinuro ang file na iyon sa /dev/null. Ang mask ay tunay na kalagayan, hindi typo sa mensahe.

Nabibigo ang instance unit dahil naaabot ng job graph nito ang root mount sa pamamagitan ng pagkasunod-sunod at ng sarili nitong mga mount requirement. Tinatanggihan ang transaksyon bago pa maisagawa ang OpenVPN binary, kaya wala sa configuration ng client ang maaaring maging dahilan. Iyon ang dahilan kung bakit walang epekto ang pagpapalit ng profile, certificate o kredensyal sa partikular na pagkabigong ito.

Tingnan ang runtime directory bago mo i-debug ang OpenVPN

Maghanap ng file na may eksaktong pangalang iyon sa direktoryo ng mga runtime unit, pagkatapos ay itanong sa systemd kung ano sa palagay nito ang unit. Mabilis ang dalawang sagot, at magkasama nilang hinihiwalay ang naiwang file sa tunay na problema sa mount.

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

Walang ganoong file ang normal na makina, at wala sa listahan ng naka-mask ang root mount. Kung ang unang command ay nag-print ng symbolic link patungo sa /dev/null, tapos na ang diagnosis. Maaaring may mask na tmp.mount din sa parehong direktoryo na ginawa ng parehong tool, at nagdudulot iyon ng parehong uri ng pagkabigo sa ibang pangalan. Tingnan ang buong direktoryo at hindi lamang ang pangalan sa error.

ls -la /run/systemd/system/*.mount

Kung malinis ang direktoryo at naka-mask pa rin ang unit, nasa ibang lugar sa search path ang mask, at ipapakita ng systemctl cat -.mount kung aling file ang kinakarga.

Burahin ang file, i-reload at simulan muli

Sapat na ang alisin ang runtime file at i-reload ang manager, at wala itong naaapektuhang anuman na galing sa isang package. I-reload bago magsimula, dahil pinapanatili ng systemd ang kalagayan ng naka-load na unit hanggang mabasa muli nito ang direktoryo.

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

Pagkatapos ay basahin ang journal ng serbisyo mismo sa halip na ipagpalagay na gumana ang pagtatama. Ang malinis na pagsisimula ay nagpapatunay lamang na tinanggap ng systemd ang unit; maaari pa ring mamatay ang client dahil sa kulang na profile, hindi maabot na peer o certificate na hindi nagva-validate. Karaniwang problema iyon ng OpenVPN na nakatago sa likod ng naka-mask na unit. Itinatala ng journal kung aling profile ang na-load at kung tunay na nabuo ang tunnel. Kung nagsimula ang unit at hindi ang tunnel, lumipat ka sa ibang problema, at iyon ay pag-unlad.

journalctl -u [email protected] -b --no-pager

Dahil ang /run ay pansamantalang filesystem, binubura rin ng reboot ang file. Kaya naging kapaki-pakinabang na pagsubok ang reboot: kung gumagana ang serbisyo pagkatapos ng reboot at nabigo muli pagkatapos ng susunod na deployment, ibinabake ang file sa image.

Pigilan itong bumalik mula sa image

Ang container o virtual-machine template na nagma-mask ng mga mount unit habang binubuo ito ay magdadala ng mask na iyon sa bawat clone. Ang susunod na nangangailangan ng filesystem ay masisira, at sinisisi ng mensahe ang mount sa halip na ang image na pinagmulan nito. Ang pagtatama sa loob ng isang tumatakbong instance ay nagtatago ng problema hanggang sa malikha ang susunod na instance.

Hanapin sa build context ang pangalan ng file at ang command na gumagawa nito, pagkatapos ay alisin ang mask mula sa template at buuin muli. Kung tunay na kailangan ang mask habang binubuo, alisin ito sa parehong layer na nagtatapos sa build, upang malinis na magsimula ang ipinapadalang image. I-verify sa bagong clone at hindi sa makina na kinumpuni mo nang manu-mano. Iyon ang tanging pagsubok na nagpapatunay na nagbago ang image.

Ang sintomas na dapat tandaan ay ang pagkakaiba ng error at ng bagay na kinokonfigure mo. Kapag nagrereklamo ang systemd tungkol sa mount habang nagsisimula ka ng client ng VPN, basahin ang pangalan ng unit sa mensahe bago ang pangalan ng serbisyo.