Ienheid -.mount is maskearre: OpenVPN-klient sil net starte
In efterbleaune -.mount-triem yn /run/systemd/system maskearret de ienheid fan 'e woartelmount, sadat elke ienheid dy't it bestânsstelsel nedich hat, mislearret foar't OpenVPN start.
Jo tsjinst mislearret foar't OpenVPN ea draait, en de flater praat oer in mount-ienheid dy't jo nea konfigurearre hawwe. Dat is it teken: systemd wegeret de hiele transaksje omdat de woartelmount-ienheid maskearre is, en jo VPN-profyl is noch net lêzen. De gewoane oarsaak is in efterbleaun triem yn 'e map foar runtime-ienheden, net in stikken fstab en net in ûntbrekkend sertifikaat. Folgje earst it triem, want dat is de goedkeapste ferklearring om út te sluten.
De flater neamt de woartelmount, net jo profyl
systemd makket de woartelmount-ienheid sels oan út 'e mount-ynformaasje fan 'e kernel, en hy neamt de ienheid -.mount omdat in streepke foar it woartelpaad stiet. Dy ienheid bestiet normaal allinnich yn it ûnthâld en hat gjin triem efter har. As de flater seit dat se maskearre is, hat immen in ienheidstriem delset dêr't systemd him lade sil en dat triem nei /dev/null wiisd. De masker is in echte tastân, net in typflater yn it berjocht.
De ynstânsje-ienheid mislearret omdat har taakgrafyk de woartelmount berikt fia oardering en fia har eigen mount-easken. De transaksje wurdt wegere foar't de OpenVPN-binêre útfierd wurdt, dus neat yn 'e konfiguraasje fan 'e klient kin de oarsaak wêze. Dêrom hat it feroarjen fan profylen, sertifikaten of oanmeldgegevens gjin effekt op dizze spesifike mislearring.
Besjoch de runtime-map foar't jo OpenVPN debugge
Sykje in triem mei krekt dy namme yn 'e map foar runtime-ienheden en freegje systemd dan wat hy tinkt dat de ienheid is. Beide antwurden binne fluch, en tegearre skiede se in efterbleaun triem fan in echt mount-probleem.
ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount
In normale masine hat sa'n triem net, en de maskearre list befettet de woartelmount net. As it earste kommando in symlink nei /dev/null printe, is de diagnoaze klear. Deselde map kin in tmp.mount-masker befetsje dat troch itselde ark makke is, en dat jout deselde klasse fan mislearring ûnder in oare namme. Sjoch nei de hiele map en net allinnich nei de namme yn 'e flater.
ls -la /run/systemd/system/*.mount
As de map skjin is en de ienheid is noch hieltyd maskearre, wennet de masker earne oars yn it sykpaad, en systemctl cat -.mount sil sjen litte hokker triem laden wurdt.
Wiskje it triem, werlaad en start op 'e nij
It runtime-triem fuorthelje en de behearder werlaad is genôch, en it rekket neat dat út in pakket komt. Werlaad foar't jo starte, want systemd hâldt de laden tastân fan 'e ienheid oant it de map wer lêst.
sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]
Lês dan it sjoernaal fan 'e tsjinst sels ynstee fan oan te nimmen dat de repaaraasje wurke hat. In skjinne start bewiist allinnich dat systemd de ienheid akseptearre hat; de klient kin noch hieltyd stjerre oan in ûntbrekkend profyl, in net berikbere peer of in sertifikaat dat net falidearret. Dat binne gewoane OpenVPN-problemen dy't efter de maskearre ienheid ferburgen wiene. It registrearret hokker profyl laden waard en oft de tunnel echt ta stân kaam. As de ienheid start en de tunnel net, binne jo nei in oar probleem ferhuze, en dat is foarútgong.
journalctl -u [email protected] -b --no-pager
Om't /run in tydlik bestânsstelsel is, rommet in werstart it triem ek op. Dat makket in werstart in nuttige test: as de tsjinst nei in werstart wurket en nei de folgjende útrôljen wer mislearret, wurdt it triem yn it image bakken.
Foarkom dat it út it image weromkomt
In kontener- of firtuele-masine-sjabloan dat by syn bou mount-ienheden maskearret, draacht dy masker nei elke kloan. Wat dêrnei it bestânsstelsel nedich hat, giet stikken, en it berjocht jout de mount de skuld ynstee fan it image dêr't it wei komt. Reparaasje yn ien rinnende ynstânsje ferberget it probleem oant de folgjende ynstânsje makke wurdt.
Sykje yn 'e bou-kontekst nei de triemnamme en nei it kommando dat dy makket, helje dan de masker út it sjabloan en bou op 'e nij. As de masker by de bou echt nedich is, helje him dan fuort yn deselde laach dy't de bou ôfslút, sadat it ferstjoerde image skjin start. Ferifiearje op in farske kloan en net op 'e masine dy't jo mei de hân reparearre hawwe. Dat is de iennige test dy't bewiist dat it image feroare is.
It symptoom om te ûnthâlden is de misferhâlding tusken de flater en datjinge dat jo konfigurearren. Wannear't systemd oer in mount klaget wylst jo in VPN-klient starte, lês dan de ienheidsnamme yn it berjocht foar't jo de tsjinstnamme lêze.