ExecStart એ shell નથી: VPN સહાયક યુનિટ સુધારવું

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

ExecStart માં પાઇપલાઇન કેમ કંઈ કરતી નથી

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

આ બેદરકારી નહીં, જાણી જોઈને છે, કારણ કે આર્ગ્યુમેન્ટની અનુમાનક્ષમ સંભાળ જ યુનિટને ઓડિટ કરી શકાય તેવા બનાવે છે. તે ફક્ત એવા લોકોને આશ્ચર્યમાં મૂકે છે જેઓ ધારે છે કે shell હાજર છે.

એવું યુનિટ લખો જે બરાબર કહે કે શું ચાલે છે

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

[Unit]
Description=Report the installed OpenVPN version

[Service]
Type=oneshot
ExecStart=/usr/sbin/openvpn --version
StandardOutput=journal
StandardError=journal

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

systemd-analyze verify /etc/systemd/system/openvpn-version.service
systemctl start openvpn-version.service

shell લોજિક સ્ક્રિપ્ટમાં રાખો

જ્યારે સહાયકને ખરેખર શરતી લોજિકની જરૂર હોય, ત્યારે તે લોજિક સ્ક્રિપ્ટમાં મૂકો અને સ્પષ્ટ રીતે બોલાવો. સ્ક્રિપ્ટને ઇન્ટરપ્રિટર લાઇન, ચલાવવાની પરવાનગી અને એવા એક્ઝિટ કોડની જરૂર છે જે સેવા જણાવી શકે. /bin/sh -c ક્વોટ કરેલી કમાન્ડ સાથે ચલાવવું કામ કરે છે, પણ તે યુનિટની અંદર ક્વોટિંગ નિયમો છુપાવે છે અને સમીક્ષા મુશ્કેલ બનાવે છે. નામવાળી સ્ક્રિપ્ટ હાથે ચકાસી શકાય અને પછી યુનિટ સંપાદિત કર્યા વિના બદલી શકાય. ઇન્ટરેક્ટિવ વપરાશકર્તાની shell પ્રોફાઇલ પર આધાર ન રાખો, કારણ કે સેવા પોતાના પર્યાવરણ સાથે શરૂ થાય છે.

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

ખરેખર અસ્તિત્વમાં હોય તે યુનિટ ચકાસો

drop-in ફાઇલો તમે સંપાદિત કર્યું હોય એવું યાદ રહેલી ફાઇલને સ્પર્શ કર્યા વિના વર્તન બદલે છે. મેનેજરે શું લોડ કર્યું અને છેલ્લી વાર શું જણાવ્યું તે વાંચો.

systemctl cat vpn-helper.service
journalctl -u vpn-helper.service -n 20 --no-pager

યુનિટ ડમ્પ લોડ ક્રમમાં drop-in ફાઇલો સમાવે છે, અને અણધારી ExecStart સામાન્ય રીતે ત્યાંથી જ આવે છે. કોઈ પણ ફેરફાર પછી મેનેજર રીલોડ કરો અને ખાતરી કરો કે નવી વ્યાખ્યા એ જ છે જે systemctl cat પ્રિન્ટ કરે છે. જર્નલ ચોક્કસ કમાન્ડ લાઇન અને એક્ઝિટ સ્થિતિ દર્શાવે છે, જે આર્ગ્યુમેન્ટની સમસ્યાને ગુમ થયેલી બાઇનરી કે પરવાનગીની ભૂલથી અલગ પાડે છે. પછી નક્કી કરો કે સહાયક હાલના VPN જીવનચક્રનો ભાગ છે કે હાથે કરવાનું નિદાન રહેવું જોઈએ, કારણ કે બીજી બેકગ્રાઉન્ડ ટનલ પ્રક્રિયા હરીફ માલિક બનાવે છે.

માંગણી પ્રમાણે સાચું આઉટપુટ પ્રિન્ટ કરતું યુનિટ સારું પ્રથમ પડાવ છે. તે હજી ટનલ નથી, અને ટનલ હોવાનો દાવો ન કરવો જોઈએ.