યુનિટ -.mount માસ્ક થયેલ છે: OpenVPN ક્લાયન્ટ શરૂ નહીં થાય

તમારી સેવા OpenVPN ક્યારેય ચાલે તે પહેલાં જ નિષ્ફળ જાય છે, અને ભૂલ એવા માઉન્ટ યુનિટ વિશે વાત કરે છે જે તમે ક્યારેય ગોઠવ્યું નથી. આ જ સંકેત છે: systemd આખો વ્યવહાર નકારી રહ્યું છે કારણ કે રૂટ માઉન્ટ યુનિટ માસ્ક થયેલ છે, અને તમારી VPN પ્રોફાઇલ હજી વંચાઈ નથી. સામાન્ય કારણ રનટાઇમ યુનિટ ડિરેક્ટરીમાં રહી ગયેલી ફાઇલ છે, તૂટેલું fstab નહીં અને ખૂટતું પ્રમાણપત્ર નહીં. પહેલાં ફાઇલનો પીછો કરો, કારણ કે તેને બાકાત કરવું સૌથી સસ્તું સમજૂતી છે.

ભૂલ રૂટ માઉન્ટનું નામ લે છે, તમારી પ્રોફાઇલનું નહીં

systemd પોતે કર્નલની માઉન્ટ માહિતીમાંથી રૂટ માઉન્ટ યુનિટ બનાવે છે અને યુનિટને -.mount કહે છે કારણ કે ડેશ રૂટ પથ દર્શાવે છે. આ યુનિટ સામાન્ય રીતે ફક્ત મેમરીમાં જ હોય છે અને તેની પાછળ કોઈ ફાઇલ હોતી નથી. જ્યારે ભૂલ કહે છે કે તે માસ્ક છે, ત્યારે કોઈએ યુનિટ ફાઇલ ત્યાં મૂકી છે જ્યાંથી systemd તેને લોડ કરશે અને તે ફાઇલને /dev/null તરફ નિર્દેશ કરી છે. માસ્ક હોવું એ વાસ્તવિક સ્થિતિ છે, સંદેશમાં ટાઇપિંગની ભૂલ નહીં.

ઇન્સ્ટન્સ યુનિટ નિષ્ફળ જાય છે કારણ કે તેનો જોબ ગ્રાફ ક્રમ અને પોતાની માઉન્ટ જરૂરિયાતો દ્વારા રૂટ માઉન્ટ સુધી પહોંચે છે. OpenVPN બાઇનરી ચાલે તે પહેલાં વ્યવહાર નકારવામાં આવે છે, તેથી ક્લાયન્ટની ગોઠવણીમાં કંઈ પણ કારણ હોઈ શકે નહીં. તેથી જ પ્રોફાઇલ, પ્રમાણપત્રો કે ક્રેડેન્શિયલ બદલવાની આ ચોક્કસ નિષ્ફળતા પર કોઈ અસર થતી નથી.

OpenVPN ડિબગ કરતાં પહેલાં રનટાઇમ ડિરેક્ટરી જુઓ

રનટાઇમ યુનિટ ડિરેક્ટરીમાં બરાબર એ જ નામની ફાઇલ શોધો, પછી systemd ને પૂછો કે તેને યુનિટ શું લાગે છે. બંને જવાબ ઝડપી છે, અને સાથે મળીને રહી ગયેલી ફાઇલને સાચી માઉન્ટ સમસ્યાથી અલગ પાડે છે.

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

સામાન્ય મશીનમાં આવી ફાઇલ હોતી નથી, અને માસ્ક કરેલી યાદીમાં રૂટ માઉન્ટ હોતું નથી. જો પહેલો આદેશ /dev/null ની સિમ્બોલિક લિંક છાપે, તો નિદાન નક્કી છે. એ જ ડિરેક્ટરીમાં એ જ સાધનોથી બનેલું tmp.mount માસ્ક પણ હોઈ શકે, અને તે બીજા નામે એ જ પ્રકારની નિષ્ફળતા સર્જે છે. આખી ડિરેક્ટરી જુઓ, ફક્ત ભૂલમાંનું નામ નહીં.

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

જો ડિરેક્ટરી સ્વચ્છ હોય અને યુનિટ હજી માસ્ક હોય, તો માસ્ક શોધમાર્ગમાં બીજે ક્યાંક છે, અને systemctl cat -.mount બતાવશે કે કઈ ફાઇલ લોડ થઈ રહી છે.

ફાઇલ કાઢી નાખો, ફરી લોડ કરો અને ફરી શરૂ કરો

રનટાઇમ ફાઇલ દૂર કરવી અને મેનેજર ફરી લોડ કરવું પૂરતું છે, અને તે પેકેજમાંથી આવેલી કોઈ વસ્તુને સ્પર્શતું નથી. શરૂ કરતાં પહેલાં ફરી લોડ કરો, કારણ કે systemd ડિરેક્ટરી ફરી ન વાંચે ત્યાં સુધી લોડ થયેલા યુનિટની સ્થિતિ રાખે છે.

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

પછી સુધારો કામ કરી ગયો એમ માનવાને બદલે સેવાનું પોતાનું જર્નલ વાંચો. સ્વચ્છ શરૂઆત ફક્ત એ સાબિત કરે છે કે systemd એ યુનિટ સ્વીકાર્યું; ક્લાયન્ટ હજી ખૂટતી પ્રોફાઇલ, અપહંચ સાથી કે ચકાસાય નહીં તેવા પ્રમાણપત્રને કારણે મરી શકે છે. આ OpenVPNની સામાન્ય સમસ્યાઓ હતી જે માસ્ક યુનિટ પાછળ છુપાયેલી હતી. જર્નલ નોંધે છે કે કઈ પ્રોફાઇલ લોડ થઈ અને ટનલ ખરેખર બની કે નહીં. જો યુનિટ શરૂ થાય અને ટનલ નહીં, તો તમે બીજી સમસ્યા પર પહોંચ્યા છો, અને આ પ્રગતિ છે.

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

કારણ કે /run કામચલાઉ ફાઇલ સિસ્ટમ છે, રીબૂટ ફાઇલ પણ ભૂંસી નાખે છે. તેથી રીબૂટ ઉપયોગી પરીક્ષણ બને છે: જો સેવા રીબૂટ પછી ચાલે અને આગલી જમાવટ પછી ફરી નિષ્ફળ જાય, તો ફાઇલ ઇમેજમાં બેક થઈ રહી છે.

તેને ઇમેજમાંથી પાછું આવતું રોકો

કન્ટેનર કે વર્ચ્યુઅલ મશીનનું ટેમ્પલેટ જે બાંધકામ દરમિયાન માઉન્ટ યુનિટ માસ્ક કરે છે, તે માસ્ક દરેક ક્લોનમાં લઈ જશે. આગળ જેને ફાઇલ સિસ્ટમ જોઈએ તે તૂટે છે, અને સંદેશ જે ઇમેજમાંથી આવ્યું તેને બદલે માઉન્ટને દોષ દે છે. એક ચાલતા ઇન્સ્ટન્સમાં સુધારો કરવાથી સમસ્યા આગલું ઇન્સ્ટન્સ બને ત્યાં સુધી છુપાય છે.

બાંધકામ સંદર્ભમાં ફાઇલનું નામ અને તેને બનાવતો આદેશ શોધો, પછી ટેમ્પલેટમાંથી માસ્ક કાઢો અને ફરી બનાવો. જો માસ્ક બાંધકામ દરમિયાન ખરેખર જરૂરી હોય, તો તેને એ જ સ્તરમાં કાઢો જે બાંધકામ પૂરું કરે છે, જેથી મોકલાતી ઇમેજ સ્વચ્છ શરૂ થાય. તાજા ક્લોન પર ચકાસો, હાથે સુધારેલા મશીન પર નહીં. ઇમેજ બદલાઈ તે સાબિત કરતું આ એકમાત્ર પરીક્ષણ છે.

યાદ રાખવા જેવું લક્ષણ છે ભૂલ અને તમે ગોઠવી રહ્યા હતા તે વચ્ચેની અસંગતિ. જ્યારે systemd માઉન્ટની ફરિયાદ કરે અને તમે VPN ક્લાયન્ટ શરૂ કરી રહ્યા હો, ત્યારે પહેલાં સંદેશમાં યુનિટનું નામ વાંચો અને પછી સેવાનું નામ.