VPN વિના ચાલેલું સુનિશ્ચિત કામ સારું લાગે છે
સ્થિતિ સફળતા કહે છે અને ડેટા ખૂટે છે. દરેક રનને ચોક્કસ કનેક્શન પર શરતી બનાવો અને શેડ્યૂલ પર ભરોસો કરવાને બદલે છોડી દેવાની ઘટનાઓ અલગથી નોંધો.
કામની સ્થિતિ સફળતા કહે છે, લોગ પૂર્ણ થયેલો રન દર્શાવે છે, અને ડેટા જૂનો છે અથવા ખૂટે છે. આ સંયોજન સામાન્ય રીતે એમ કહે છે કે સુનિશ્ચિત કામ તેને જરૂરી માર્ગ વિના શરૂ થયું, અને નીચે કંઈક નિષ્ફળતાને ગળી ગયું. સમયસર ચાલુ થતું શેડ્યૂલ નેટવર્ક તૈયાર હતું કે નહીં તે વિશે કંઈ કહેતું નથી. આ બે હકીકતો વચ્ચેનું અંતર એ જ જગ્યા છે જ્યાં આ નિષ્ફળતા રહે છે.
પ્રવેશ રનનો છે, cron ફાઇલના અસ્તિત્વનો નહીં.
લીલો રન પૂર્ણ થયેલું કામ નથી
શેડ્યુલર નોંધે છે કે પ્રક્રિયા શરૂ થઈ અને પછી બહાર નીકળી; તેને ખબર નથી કે તે પ્રક્રિયા જે સંસાધન માટે અસ્તિત્વમાં છે ત્યાં પહોંચી કે નહીં. જે સ્ક્રિપ્ટ નિષ્ફળ કનેક્શનને ખાલી પરિણામ તરીકે લે છે, અથવા ભૂલ પકડીને શૂન્ય સાથે બહાર નીકળે છે, તે કાયમ સ્વસ્થ દેખાશે. લક્ષણ લાલ સ્થિતિ નથી; તે ખૂટતા કામ સાથે જોડાયેલી વિશ્વસનીય સ્થિતિ છે.
કેવી રીતે ચકાસવું તે નક્કી કરતા પહેલાં રનને ખરેખર શું જોઈએ તેનું નામ આપો. બેકઅપને ખાનગી DNS અને પ્રમાણિત એન્ડપોઇન્ટની જરૂર પડી શકે, માત્ર ટનલ પ્રક્રિયાની નહીં.
કનેક્શન ચકાસો, ઇન્ટરફેસનું નામ નહીં
tun0 નામનું ઇન્ટરફેસ મહત્વપૂર્ણ સેશન વિના અસ્તિત્વમાં હોઈ શકે, અને બીજું કનેક્શન તે નામ ધરાવી શકે. કામ જે ચોક્કસ ઑબ્જેક્ટ પર આધાર રાખે છે તે ચકાસો: એક પ્રોફાઇલ ઓળખ, એક સેવા ઉદાહરણ, અથવા સંસાધન સામે નાની મંજૂર કામગીરી. ચકાસણીને સમય-મર્યાદિત રાખો, અને ઓળખપત્રોને પ્રક્રિયા આર્ગ્યુમેન્ટ અને નિદાન લોગની બહાર રાખો.
ડિસ્કનેક્ટ થયાનું પરિણામ પણ વ્યાખ્યાયિત કરો. સામાન્ય છોડી દેવું, ટૂંકી વિન્ડોમાં ફરી પ્રયાસ, અને ઓપરેટરને દેખાતી ચૂકેલી સમયમર્યાદા ત્રણ અલગ જવાબો છે, અને પુનરાવર્તિત શેડ્યૂલ તેમની વચ્ચે પસંદગી કરતું નથી.
છોડી દેવા અને નિષ્ફળતા અલગ પરિણામો છે
[Service] Type=oneshot User=worker ExecCondition=/usr/local/libexec/check-office-path ExecStart=/usr/local/bin/private-task
systemd જમાવટમાં, ExecCondition= કામભાર પહેલાં તે ચકાસનાર ચલાવે છે. તેનું બહિર્ગમન વર્તન ચોક્કસ છે: શૂન્ય ચાલુ રાખે છે, એકથી 254 સુધીના કોડ યુનિટને નિષ્ફળ તરીકે ચિહ્નિત કર્યા વિના બાકીના શરૂઆતના આદેશો છોડી દે છે, અને 255 અથવા અસામાન્ય સમાપ્તિ તેને નિષ્ફળ કરે છે. આ ત્રણ અલગ સંકેતો આપે છે, જે ફક્ત ત્યારે જ ઉપયોગી છે જ્યારે ચકાસનારનો કરાર જાણી જોઈને તેમના પર મેપ કરવામાં આવે. સફળતાને ફરીથી વ્યાખ્યાયિત કરતી સેટિંગ્સ ચિત્ર બદલી શકે છે, તેથી મેપિંગનું દસ્તાવેજીકરણ કરો.
છોડી દેવાની નોંધ રાખવી એ જ ડિઝાઇનને પ્રામાણિક બનાવે છે. ક્યાંય દેખાતું ન હોય તેવું છોડી દેવાયેલું રન સફળ થયેલા રનથી અલગ પારખી શકાતું નથી, અને દરેક ચકાસનાર ભૂલને શાંત છોડી દેવા તરીકે ગણવું તૂટેલી જમાવટને અનિશ્ચિત કાળ સુધી છુપાવે છે.
આખો રન સાચવો, ફક્ત શરૂઆત નહીં
તૈયારીની ચકાસણી શરૂ કરતા પહેલાં દુનિયાનું નિરીક્ષણ કરે છે; તે પછી દરેક સોકેટ પર પહેરો ભરતી નથી. જ્યારે આ કામ માટે સીધો માર્ગ ક્યારેય સ્વીકાર્ય ન હોય, ત્યારે મંજૂર આઉટગોઇંગ નીતિ જોડો જે સતત લાગુ થાય અને DNS, IPv6 અને ટનલના પોતાના પરિવહનને આવરે. હોસ્ટની વૈશ્વિક IPv6 સ્થિતિ બદલવી કામ પરની મર્યાદિત નીતિનો વિકલ્પ નથી.
નવી ઘટના હજી ચાલતા કામને ઓવરલેપ કરી શકે છે કે નહીં તે નક્કી કરો, તે નિયમ કામભાર માલિક પાસે રાખો, અને ડેટા કામગીરી માટે ફરી પ્રયાસને સુરક્ષિત બનાવો. ડિસ્કનેક્ટ થવા પર કામ રોકવું કામને મર્યાદિત કરે છે પણ ફોલબેક ટ્રાફિક વિશે કંઈ ખાતરી આપતું નથી.
ત્રણ કિસ્સામાં કાર્યપ્રવાહ સ્વીકારો: તૈયાર માર્ગ, અનુપલબ્ધ માર્ગ, અને રન દરમિયાન નુકસાન. આનાથી ઓછું શેડ્યૂલની પરીક્ષા કરે છે, કામની નહીં.