openvpn --errors-to-stderr ay isang opsyon sa paglulunsad, hindi isang error

Isang command line na may --errors-to-stderr mukhang reklamo at hindi ito reklamo. Ang salita ay bahagi ng pangalan ng isang opsyon, tulad ng pangalan ng log file na walang sinasabi tungkol sa nilalaman nito. Bago mo baguhin ang anumang configuration, tiyakin kung ano talaga ang binabasa mo.

May tatlong sangay ang desisyon: ang linya ay ang paglulunsad mismo, ang linya ay output na inilimbag ng programa, o ang linya ay tekstong inulit ng wrapper bago magsimula ang VPN. Bawat sangay ay tumutukoy sa ibang lugar na titingnan, at isa lamang sa kanila ang mensahe mismo ng VPN.

Ang pangalan ng opsyon ay hindi mensahe ng estado

Para sa Community OpenVPN, --errors-to-stderr iniaayos ang output ng error sa standard error sa halip na standard output. Ito ay pagpili ng stream, hindi filter ng kalubhaan, at hindi ito lumilikha ng error. Ang --log o --log-append sa bandang huli ay maaaring mag-redirect ng parehong mensahe sa isang file, kaya nakadepende ang epekto ng flag sa natitirang bahagi ng command. Ang Ang logging reference mula sa pinagmulan ang nagtatakda ng pagkakasunod-sunod na iyon.

Kaya ang pagkakaroon ng flag ay nagsasabi kung saan pupunta ang mga error. Hindi nito sinasabi na may nangyari.

Linya ng paglulunsad o output ng proseso

Simulan sa pagtatanong kung sino ang naglimbag ng teksto. Ang service unit, application bundle o shell wrapper ay madalas na inuulit ang buong argv bago sumulat ng anuman ang proseso ng VPN. Ang ulit na iyon ay hindi makikilala mula sa linya ng estado kung bahagi lamang ang nakikita mo.

Kung ang linya ay mula sa wrapper, hindi pa tumatakbo ang VPN at wala itong iniuulat. Tumingin paibaba sa output sa unang mensaheng may timestamp o pangalan ng subsystem.

Kung ang linya ay mula sa proseso ng VPN, ito ay ang tawag pa rin. Hindi inililimbag ng OpenVPN ang sarili nitong command line bilang error, at ang mahahalagang mensahe ay kasunod nito.

Hanapin ang proseso at ang resulta nito

Tiyakin kung tumatakbo pa ang proseso. Ang kliyenteng buhay at paulit-ulit na sumusubok ay ibang-iba sa kliyenteng agad na umalis, at ang parehong command line ay nauuna sa dalawa.

Pagkatapos ay basahin ang resulta sa pamamagitan ng component na nagmamay-ari ng proseso. Sa systemd, ito ang journal ng unit; sa desktop app, ito ang sariling log o console ng app. Ang exit status kasama ang mga huling mensahe ay sumasagot sa tanong na pahiwatig lamang ng pangalan ng opsyon.

Ang error sa pag-parse ng configuration, nawawalang file, tinanggihang credential at peer timeout ay apat na magkakaibang pangyayari. Dumarating ang mga ito sa isang stream. Kailangan nila ng apat na magkakaibang pagwawasto. Magpasya kung alin ang mayroon ka bago hawakan ang profile, at sipiin ang eksaktong mensahe kapag humihingi ka ng tulong.

Kailan karapat-dapat ang flag sa lugar nito

Karapat-dapat ang flag sa lugar nito kapag ang stdout ay nagdadala ng data at hindi dapat itong madumihan ng mga error, o kapag hinuhuli ng wrapper ang dalawang stream nang hiwalay. Sa isang foreground session sa terminal, dumarating sa harap mo ang dalawang stream. Sa ganitong kaso, bihirang mabago ng pagkakaibang ito ang ginagawa mo.

Panatilihin ito kung nakadepende ang kalakip na script sa paghihiwalay. Ang pag-alis nito dahil mukhang nakababahalang ang pangalan ay nagbabago kung saan lumilitaw ang mga mensahe at wala nang iba pang inaayos.

Ano ang hindi dapat baguhin

Huwag ituring ang opsyon na hakbang sa pag-aayos. Hindi maaayos ng pagtanggal nito ang isang certificate, ruta o kabiguan sa authentication.

Kung ang tawag ay may --config stdin, ang configuration ay pinapasok sa pamamagitan ng standard input. Ito ay hiwalay na desisyon tungkol sa kung paano ibinibigay ang file. Baguhin ang isang bagay sa isang pagkakataon, at basahin muli ang aktwal na mensahe bago baguhin ang pangalawa.