Palvelusi epäonnistuu ennen kuin OpenVPN edes käynnistyy, ja virhe puhuu liitosyksiköstä, jota et koskaan määrittänyt. Se on vihje: systemd hylkää koko transaktion, koska juuren liitosyksikkö on peitetty, eikä VPN-profiiliasi ole vielä luettu. Tavallinen syy on ajonaikaisten yksikköjen hakemistoon jäänyt tiedosto, ei rikkinäinen fstab eikä puuttuva varmenne. Seuraa ensin tiedostoa, koska se on halvin selitys, jonka voi sulkea pois.

Virhe nimeää juuren liitoksen, ei profiiliasi

systemd luo juuren liitosyksikön itse ytimen liitostiedoista ja nimeää yksikön -.mount, koska yhdysviiva tarkoittaa juuripolkua. Tämä yksikkö on yleensä olemassa vain muistissa, eikä sen takana ole tiedostoa. Kun virhe sanoo, että se on peitetty, joku on laittanut yksikkötiedoston sinne, mistä systemd sen lataa, ja osoittanut tiedoston kohteeseen /dev/null. Peite on todellinen tila, ei viestin kirjoitusvirhe.

Instanssiyksikkö epäonnistuu, koska sen työkaavio saavuttaa juuren liitoksen järjestyksen ja omien liitosvaatimustensa kautta. Transaktio hylätään ennen kuin OpenVPN-binääri suoritetaan, joten mikään asiakkaan kokoonpanossa ei voi olla syynä. Siksi profiilien, varmenteiden tai tunnistetietojen vaihtaminen ei vaikuta tähän nimenomaiseen vikaan.

Katso ajonaikaista hakemistoa ennen kuin alat selvittää OpenVPN:n ongelmaa

Etsi täsmälleen sen nimistä tiedostoa ajonaikaisten yksikköjen hakemistosta ja kysy sitten systemd:ltä, mitä se luulee yksikön olevan. Molemmat vastaukset ovat nopeita, ja yhdessä ne erottavat jääneen tiedoston todellisesta liitosongelmasta.

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

Normaalissa koneessa ei ole sellaista tiedostoa, eikä peitettyjen luettelo sisällä juuren liitosta. Jos ensimmäinen komento tulostaa symbolisen linkin kohteeseen /dev/null, diagnoosi on varma. Samassa hakemistossa voi olla samojen työkalujen luoma tmp.mount-peite, ja se tuottaa saman vikaluokan toisella nimellä. Katso koko hakemistoa, älä vain virheen nimeä.

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

Jos hakemisto on puhdas ja yksikkö on yhä peitetty, peite on muualla hakupolussa, ja systemctl cat -.mount näyttää, mikä tiedosto ladataan.

Poista tiedosto, lataa uudelleen ja käynnistä taas

Ajonaikaisen tiedoston poistaminen ja hallinnan uudelleenlataus riittää, eikä se koske mihinkään paketista tulleeseen. Lataa uudelleen ennen käynnistystä, koska systemd pitää ladatun yksikön tilan, kunnes lukee hakemiston uudelleen.

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

Lue sitten palvelun oma loki sen sijaan, että olettaisit korjauksen toimineen. Puhdas käynnistys todistaa vain, että systemd hyväksyi yksikön; asiakas voi silti kaatua puuttuvaan profiiliin, tavoittamattomaan vastapuoleen tai varmenteeseen, joka ei valikoidu. Ne ovat tavallisia OpenVPN-ongelmia, jotka olivat piilossa peitetyn yksikön takana. Loki kirjaa, mikä profiili ladattiin ja muodostuiko tunneli todella. Jos yksikkö käynnistyy eikä tunneli, olet siirtynyt toiseen ongelmaan, ja se on edistystä.

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

Koska /run on tilapäinen tiedostojärjestelmä, uudelleenkäynnistys tyhjentää myös tiedoston. Se tekee uudelleenkäynnistyksestä hyödyllisen testin: jos palvelu toimii uudelleenkäynnistyksen jälkeen ja epäonnistuu taas seuraavan käyttöönoton jälkeen, tiedosto leivotaan imagen sisään.

Estä sen paluu imagesta

Kontti- tai virtuaalikonepohja, joka peittää liitosyksiköt rakennusvaiheessa, kuljettaa peitteen jokaiseen klooniin. Seuraava tiedostojärjestelmää tarvitseva hajoaa, ja viesti syyttää liitosta eikä imagoa, josta se tuli. Yhden käynnissä olevan instanssin sisällä korjaaminen piilottaa ongelman seuraavan instanssin luontiin asti.

Etsi rakennuskontekstista tiedostonimi ja sen luova komento, poista sitten peite pohjasta ja rakenna uudelleen. Jos peitettä todella tarvitaan rakennuksen aikana, poista se samassa kerroksessa, joka päättää rakennuksen, jotta toimitettava image käynnistyy puhtaana. Vahvista tuoreessa kloonissa, älä koneessa, jonka korjasit käsin. Se on ainoa testi, joka todistaa, että image muuttui.

Muistettava oire on virheen ja määrittämäsi asian välinen ristiriita. Kun systemd valittaa liitoksesta samalla kun käynnistät VPN-asiakasta, lue viestistä yksikön nimi ennen palvelun nimeä.

Aiheeseen liittyvät artikkelit