Yksikkö -.mount on peitetty: OpenVPN-asiakas ei käynnisty
Tilapäinen -.mount-tiedosto hakemistossa /run/systemd/system peittää juuren liitosyksikön, joten jokainen tiedostojärjestelmää tarvitseva yksikkö epäonnistuu ennen kuin OpenVPN käynnistyy.
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ä.