PID ഫയൽ ഇതിനകം ഉള്ളതിനാൽ ലോഞ്ചർ OpenVPN ആരംഭിക്കാൻ വിസമ്മതിക്കുമ്പോൾ, എവിടെയോ ഒരു ടണൽ പ്രവർത്തിക്കുന്നു എന്ന് വായിക്കുന്നത് സ്വാഭാവികമാണ്. ആ വായന പലപ്പോഴും തെറ്റാണ്, അതിനാൽ എന്തെങ്കിലും ഇല്ലാതാക്കുന്നതിന് മുൻപ് പരിശോധിക്കുന്നത് യോഗ്യമാണ്. റൺടൈം ഡയറക്ടറിയിലെ ഫയൽ കണക്കാണ്, കണക്ക് പ്രോസസ് അവശേഷിപ്പിക്കാത്ത ക്രാഷുകളെയും റീബൂട്ടുകളെയും തടസ്സപ്പെട്ട ഷട്ട്ഡൗണുകളെയും അതിജീവിക്കുന്നു. രണ്ട് ചോദ്യങ്ങളാണ് കാര്യം തീരുമാനിക്കുന്നത്: ജീവനുള്ള പ്രോസസ് ഉണ്ടോ, ആ പ്രോസസ് ഈ ഇൻസ്റ്റൻസിന്റേതാണോ.

ഫയലിൽ നിന്നല്ല, സേവനത്തിൽ നിന്ന് തുടങ്ങുക

വിസമ്മതം സാധാരണയായി OpenVPN-ൽ നിന്നല്ല, ലോഞ്ചറിൽ നിന്നാണ് വരുന്നത്. അത് ഒരു പാത്ത് വായിക്കുന്നു, അവിടെ എന്തോ കണ്ടെത്തുന്നു, കോൺഫിഗറേഷൻ വിശകലനം ചെയ്യുന്നതിന് മുൻപ് നിൽക്കുന്നു. അതിനാൽ ആദ്യ ചോദ്യം ടണലിനെക്കുറിച്ചല്ല, ലോഞ്ചറിന്റെ കരാറിനെക്കുറിച്ചാണ്.

സന്ദേശം അച്ചടിച്ച യൂണിറ്റോ സ്ക്രിപ്റ്റോ വായിച്ച് മൂന്ന് കാര്യങ്ങൾ ശ്രദ്ധിക്കുക: അത് പരിശോധിക്കുന്ന പാത്ത്, പ്രഖ്യാപിക്കുന്ന സേവന തരം, ഫയൽ എഴുതാനുള്ള ഉത്തരവാദിത്തം അതിനുണ്ടോ എന്നത്. ആധുനിക യൂണിറ്റ് ലളിതമോ അറിയിപ്പ് അധിഷ്ഠിതമോ ആയ മേൽനോട്ടം ഉപയോഗിച്ച് PID ഫയലിൽ ഒരിക്കലും തൊടാതിരിക്കാം, പഴയ init സ്ക്രിപ്റ്റ് സ്വയം ഒന്ന് സൃഷ്ടിച്ചേക്കാം. ഒരു മാതൃകയിലെ പരിശോധന മറ്റൊന്നിലേക്ക് പകർത്തുന്നത് കൃത്യമായി ഇത്തരം വിസമ്മതം ഉണ്ടാക്കുന്നു. എന്തെങ്കിലും വ്യാഖ്യാനിക്കുന്നതിന് മുൻപ് ഏത് മാതൃകയാണ് ഉപയോഗിക്കുന്നതെന്ന് കണ്ടെത്തുക.

അപ്പോൾ മാത്രമാണ് ചോദ്യം ഒരു ഇൻസ്റ്റൻസ് യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നുണ്ടോ എന്നതാകുന്നത്.

ആ ഐഡന്റിഫയർ നിങ്ങളുടെ ഇൻസ്റ്റൻസിന്റേതാണോ എന്ന് പരിശോധിക്കുക

ഫയലിലെ ഒരു സംഖ്യ ഒരു സംഖ്യ എഴുതപ്പെട്ടു എന്ന് തെളിയിക്കുന്നു. ആ ഐഡന്റിഫയറുള്ള പ്രോസസ് ഇപ്പോൾ നിലവിലുണ്ടെന്ന് അത് തെളിയിക്കുന്നില്ല, പ്രോസസ് നിങ്ങളുടേതാണെന്നും തെളിയിക്കുന്നില്ല, കാരണം റീബൂട്ടിന് ശേഷം ഐഡന്റിഫയറുകൾ വീണ്ടും ഉപയോഗിക്കുന്നു.

പ്രോസസിന്റെ ആരംഭ സമയം ഫയലിന്റെ സമയമുദ്രയുമായി, എക്സിക്യൂട്ടബിൾ യൂണിറ്റിന്റെ കമാൻഡുമായി, സേവന അംഗത്വം യൂണിറ്റിന്റെ പേരുമായി താരതമ്യം ചെയ്യുക. മൂന്നിലൊന്നിൽ പൊരുത്തക്കേടുണ്ടെങ്കിൽ നിങ്ങൾ ടണലല്ല, കണക്കാണ് നോക്കുന്നത്.

കണ്ടെയ്നറുകളോ നിരവധി നാമസ്ഥലങ്ങളോ പ്രവർത്തിപ്പിക്കുന്ന ഹോസ്റ്റിൽ ഒരു ഐഡന്റിഫയർ ഒരു കാഴ്ചയിൽ അർത്ഥവത്താകാം, മറ്റൊന്നിൽ ഇല്ലാതിരിക്കാം. പ്രോസസ് കാണാതിരിക്കുന്നതും അതിന്റെ അഭാവത്തിന് തെളിവല്ല, നിങ്ങളുടെ അക്കൗണ്ടിന് അത് പരിശോധിക്കാനാകില്ലെങ്കിൽ. നിഗമനങ്ങളിൽ എത്തുന്നതിന് മുൻപ് ലോഞ്ചർ ഉപയോഗിക്കുന്ന സന്ദർഭത്തിൽ നിന്ന് പരിശോധിക്കുക.

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

ഫയലിനെക്കുറിച്ച് ലോഞ്ചർ എന്ത് വാഗ്ദാനം ചെയ്തു

PIDFile= സേവന മാനേജറോട് പ്രധാന പ്രോസസിന്റെ ഐഡന്റിഫയർ എവിടെ നിന്ന് വായിക്കണമെന്ന് പറയുന്നു. മാനേജർ ആ ഫയൽ എഴുതുന്നില്ല, പക്ഷേ ഷട്ട്ഡൗണിന് ശേഷം അവശേഷിക്കുന്നത് നീക്കം ചെയ്യുന്നു, അതുകൊണ്ടാണ് തടസ്സപ്പെട്ട പുറത്തുപോക്ക് ഒരു ഫയൽ അവശേഷിപ്പിക്കാൻ കഴിയുന്നത്.

ഉത്തരവാദിത്തത്തിന്റെ ഈ വിഭജനം ആളുകൾ ബഗുകളായി റിപ്പോർട്ട് ചെയ്യുന്ന രണ്ട് ലക്ഷണങ്ങളെ വിശദീകരിക്കുന്നു. ഒരിക്കലും പ്രത്യക്ഷപ്പെടാത്ത ഫയൽ എന്നാൽ ഡീമണോ അതിന്റെ സ്ക്രിപ്റ്റോ അത് എഴുതാൻ പരാജയപ്പെട്ടു എന്നാണ്, മേൽനോട്ടം തെറ്റായി ക്രമീകരിച്ചു എന്നല്ല. സ്റ്റോപ്പിന് ശേഷം അവശേഷിക്കുന്ന ഫയൽ എന്നാൽ ഷട്ട്ഡൗൺ പാത്ത് ഒരിക്കലും പൂർത്തിയായില്ല എന്നാണ്.

മേൽനോട്ടത്തിന് പ്രധാന പ്രോസസ് നേരിട്ട് ട്രാക്ക് ചെയ്യാനാകുമ്പോൾ ഈ സമ്പ്രദായം ഒഴിവാക്കാൻ നിലവിലെ മാർഗ്ഗനിർദ്ദേശങ്ങൾ നിർദ്ദേശിക്കുന്നതിന്റെ കാരണവും ഇത് വിശദീകരിക്കുന്നു. ആ മാർഗ്ഗനിർദ്ദേശം പാക്കേജ് ചെയ്ത യൂണിറ്റിന്റെ തരം മാറ്റാനുള്ള അനുമതിയല്ല, കാരണം ഡീമണിന്റെ ഫോർഗ്രൗണ്ട്, ഫോർക്കിംഗ് അല്ലെങ്കിൽ അറിയിപ്പ് സ്വഭാവം യൂണിറ്റ് പ്രഖ്യാപിക്കുന്നതുമായി ഒത്തുപോകണം. ഡീമൺ മാറ്റാതെ തരം മാറ്റുക, ടണൽ പ്രവർത്തിക്കുമ്പോൾ പരാജയം റിപ്പോർട്ട് ചെയ്യുന്ന യൂണിറ്റ് ലഭിക്കും, അല്ലെങ്കിൽ നേരെ മറിച്ചും. ജോഡി ഒത്തുപോകട്ടെ, അല്ലെങ്കിൽ രണ്ടും വിടുക. systemd സേവന റഫറൻസ് ഉടമസ്ഥതയുടെ വിഭജനം വിവരിക്കുന്നു.

വൃത്തിയായ ഷട്ട്ഡൗൺ തടസ്സപ്പെട്ട പുറത്തുപോക്കിനെതിരെ

വൃത്തിയായ സ്റ്റോപ്പ് ഡീമണിനോട് പുറത്തുപോകാൻ ആവശ്യപ്പെടുന്നു, അതിനായി കാത്തിരിക്കുന്നു, മാനേജറെ സ്വന്തം കണക്ക് ശരിയാക്കാൻ അനുവദിക്കുന്നു. തടസ്സപ്പെട്ട പുറത്തുപോക്ക്, കൊല്ലപ്പെട്ട പ്രോസസ് അല്ലെങ്കിൽ ഷട്ട്ഡൗണിനിടയിൽ റീബൂട്ട് ആ ക്രമത്തിന്റെ ഭാഗങ്ങൾ ഒഴിവാക്കുന്നു, അവശേഷിക്കുന്നത് ഫയലാണ്. ക്രാഷിന് ശേഷം ഒന്ന് കണ്ടെത്തുന്നത് ഷട്ട്ഡൗൺ പൂർത്തിയായില്ല എന്നാണ് പറയുന്നത്, എന്തോ കേൾക്കുന്നു എന്നല്ല.

ഫയലിന്റെ സമയമുദ്ര അവസാന ബൂട്ടുമായും യൂണിറ്റിന്റെ അവസാന സ്റ്റോപ്പുമായും താരതമ്യം ചെയ്യുക.

തുടർന്ന് ജീവനുള്ള തെളിവുകൾ നേരിട്ട് പരിശോധിക്കുക. VPN പോർട്ടിൽ ബന്ധിച്ച സോക്കറ്റും വിലാസമുള്ള ടണൽ ഇന്റർഫേസും എന്തോ പ്രവർത്തിക്കുന്നു എന്നതിന് തെളിവാണ്, റൺടൈം ഡയറക്ടറിയിലെ ടെക്സ്റ്റ് ഫയൽ ഒരിക്കലും അങ്ങനെയാകാത്ത രീതിയിൽ. രണ്ടും ഇല്ലെങ്കിൽ, ഫയൽ എന്ത് അവകാശപ്പെട്ടാലും ഒന്നും പ്രവർത്തിക്കുന്നില്ല.

ശീലമായി ഫയൽ ഇല്ലാതാക്കുന്നത് നിർത്തുക

ഒരു ഇൻസ്റ്റൻസും അതിന്റെ ഉടമയല്ലെന്നും ലോഞ്ചർ ഈ സ്വഭാവം രേഖപ്പെടുത്തുന്നുവെന്നും സ്ഥാപിച്ച ശേഷം അത് ഇല്ലാതാക്കുന്നത് നിയമാനുസൃതമായ വീണ്ടെടുപ്പ് ഘട്ടമാണ്.

തുടക്കത്തിന് മുൻപുള്ള സ്ഥിരമായ ശീലമെന്ന നിലയിൽ അത് നിങ്ങൾ ഒഴിവാക്കുന്ന പരിശോധനയെ തന്നെ തകർക്കുന്നു. ഓരോ വൃത്തിയായ സ്റ്റോപ്പിനും ശേഷം പഴയ ഫയലുകൾ മടങ്ങിയെത്തുന്നുവെങ്കിൽ, എഴുതുന്നയാളും ഷട്ട്ഡൗൺ ജീവിതചക്രവും പാത്തിന്റെ ഉടമസ്ഥതയിൽ യോജിക്കുന്നില്ല, ആ വിയോജിപ്പാണ് ശരിയാക്കാൻ യോഗ്യമായ ബഗ്.

ഹോസ്റ്റിലേക്ക് പ്രവേശിക്കാനുള്ള സ്വതന്ത്ര മാർഗം സൂക്ഷിക്കുക, അതിന്റെ സാധാരണ മാനേജർ വഴി ഒരു ഇൻസ്റ്റൻസ് ആരംഭിക്കുക, ആദ്യ ഫലം വായിക്കുക. അടുത്ത വ്യക്തിക്ക് പ്രവർത്തിക്കുന്നതോ തന്നെത്തന്നെ വിശദീകരിക്കുന്നതോ ആയ ഒരു യൂണിറ്റ് ലഭിക്കുന്നു.

അനുബന്ധ ലേഖനങ്ങൾ