OpenVPN-ը մեկնարկեց, բայց ոչինչ չտպեց․ նախ ստուգեք log-append-ը
Ձեռքի մեկնարկի լռությունը ձախողում չէ։ Կարդացեք log- և log-append-ը բեռնված պրոֆիլում, ապա համապատասխանեցրեք ֆայլը և նրա ժամանակները գործընթացին։
Դուք OpenVPN-ը գործարկում եք shell-ից կոնֆիգուրացիայի ֆայլով, և տերմինալը մնում է առանց որևէ արտածման։ Ո՛չ բաններ, ո՛չ սխալ, ո՛չ հուշում։ Բնազդն ասում է, թե մեկնարկը ձախողվել է, ուստի գործարկում եք ևս մեկ պատճեն, հետո ևս մեկը, և մեքենայի վրա մնում են մի քանի կիսակարգավորված օրինակներ։ Այս ամենից առաջ պրոֆիլում ստուգեք մի հրահանգ, որն արդեն մատյանը ուղղել է այլ տեղ։ Լռությունը կոնսոլի հատկություն է, ոչ թե գործընթացի։
Լռությունն ունի երկու շատ տարբեր բացատրություն
Առաջինն այն է, որ գործընթացը լավ է աշխատում և գրում է մի ֆայլի մեջ, որը դուք չեք հետևում։ Երկրորդն այն է, որ այն անմիջապես դուրս եկավ նույն ֆայլում գրանցված սխալով։
Երկուսն էլ թողնում են դատարկ տերմինալ, և մեկ հարց բաժանում է նրանց․ հիմա գործընթաց կա՞, և ի՞նչ կա այն ֆայլում, որին ասվել էր գրել։ Պատասխանեք դրան նախքան կոնֆիգուրացիային նորից դիպչելը։ Արտածում ստանալու համար վերագործարկելը այն ճանապարհն է, որով երկու օրինակ սկսում են կռվել մեկ թունելային սարքի և նույն պորտի համար, ինչը ստեղծում է սխալներ, որոնք ոչ մի կապ չունեն սկզբնական խնդրի հետ։
Գտեք հրահանգը, ապա գտեք գործընթացը։
ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf
Գտեք այն նպատակակետը, որն օգտագործում է ընթացող գործընթացը
Կարդացեք այն պրոֆիլը, որով գործընթացն իրականում մեկնարկել է, ոչ թե այն, որը խմբագրել եք։ Ծառայության կողմից կառավարվող օրինակը սովորաբար բեռնում է այլ ուղի և աշխատում է այլ աշխատանքային պանակով, ուստի հարաբերական ֆայլանունը լուծվում է մի տեղ, որը չէիք սպասում։
Հստակ cd հրահանգը սրում է այդ տարբերությունը, քանի որ հարաբերական ուղին շարժվում է պանակի փոփոխության հետ։ Եթե ժառանգել եք այս կոնֆիգուրացիան, ֆայլը կարող է լինել մի տեղ, որտեղ հիմա ոչ ոք չէր փնտրի։
Համեմատեք ֆայլի փոփոխման ժամանակը այն պահի հետ, երբ գործարկեցիք այն։ Անցյալ շաբաթվա մատյանը ապացույց է անցյալ շաբաթվա մասին։ Ապա կարդացեք փոփոխված ֆայլի վերջին տողերը և այնտեղ եղածը համարեք ձեր բաց թողած մեկնարկի հաղորդագրությունը։
log ընդդեմ log-append-ի․ ապացույց և ջնջում
log-append-ը ավելացնում է այն ամենին, ինչ արդեն կա ֆայլում։ log-ը բացում է ֆայլը գրելու համար և կտրում է այն, ուստի երկուսի միջև փոխելը կարող է ջնջել այն աշխատանքը, որը պատրաստվում էիք կարդալ։
Եթե ինչ-որ մեկը վրիպազերծման ընթացքում փոխել է հրահանգը, նախորդ ապացույցն արդեն անհետացել է, և ֆայլի չափը կթվա կասկածելի փոքր։ Արժե դա իմանալ նախքան երկու աշխատանք համեմատելը և եզրակացնելը, թե ինչ-որ բան փոխվել է։ Ջնջեք մատյանը դիտավորյալ կամ պահեք այն, բայց իմացեք, թե որն արեցիք։ Դիտավորյալ հեռացված ապացույցն ավելի հեշտ է հիմնավորել, քան պատահաբար կորցրածը։
Ոչ մի տարբերակ չի ստեղծում բացակայող ծնողական պանակներ, և ոչ մեկը չի տալիս հասանելիություն ֆայլային համակարգի թույլտվությունների կամ ծառայության ավազարկղի միջոցով։ Կոնֆիգուրացիայում ճիշտ թվացող ուղին դեռ կարող է անգրելի լինել այն հաշվի համար, որի տակ աշխատում է դեմոնը, և այդ դեպքում դեմոնը կարող է ձախողվել նախքան որևէ բան հայտնելը։ Նախքան ֆայլանունը խնդիր համարելը ստուգեք՝ պանակը գոյություն ունի՞ և ով է դրա տերը։
Երբ ծառայության փաթաթանը որսում է արտածումը
systemd-ի ներքո ստանդարտ արտածումն ու սխալը գնում են journal, եթե բացահայտ ֆայլային հրահանգը առաջնահերթություն չունի, և մատակարարի փաթաթանը կարող է դրանք որսալ բոլորովին այլ տեղ։
Այդ պատճառով նույն պրոֆիլը տարբեր կերպ է վարվում shell-ից և unit-ից։ Unit-ի միջավայրը, նրա աշխատանքային պանակը և ստանդարտ հոսքերը տարբերվում են ձեր ինտերակտիվ shell-ից։ Հարաբերական ուղին կարող է լուծվել մի համատեքստում և երկրորդում ոչ մի տեղ չհասնել։ Երբ երկուսը չեն համընկնում, կարդացեք unit-ի սահմանումը, ոչ թե պրոֆիլը։
Համեմատեք մեկնարկի երկու դասավորությունները՝ փոխարենը եզրակացնելու, որ դրանցից մեկը կոտրված է։ Կարդացեք unit-ի հրամանի տողը և նրա միջավայրը, ապա կարդացեք journal-ը նույն ժամանակահատվածի համար։ Եթե փաթաթանը արտածումը ուղղում է իր սեփական ֆայլին, այդ ֆայլը հիմա ձեր մատյանն է, և OpenVPN-ի հրահանգները կապ չունեն այն բանի հետ, թե ուր գնացին հաղորդագրությունները։
Բարձրացրեք մանրամասնությունը միայն այն բանից հետո, երբ կարողանաք կարդալ այն
Նպատակակետը գտնելուց առաջ մանրամասնությունը բարձրացնելը միայն ավելի շատ տեքստ է արտադրում մի տեղ, որին չեք նայում։
Երբ իմանաք, թե ուր է հասնում արտածումը, չափավոր մակարդակը ցույց է տալիս, որ պրոֆիլը վերլուծվում է, և կապը փորձարկվում է։ Երկուսը կամ երեքը բավական են մեկնարկի խնդրի համար։ Ավելի բարձր մակարդակներն արժանի են իրենց տեղին, երբ ձախողումը բանակցության մանրամասնություն է, և դրանք նաև արագ մեծացնում են ֆայլը։
Ապա կարդացեք իրական սխալը։ Լուռ տերմինալը ոչինչ չի ապացուցում այն մասին, թե արդյոք թունելը բարձրացավ, և ֆայլում գրանցված ձախողումն է, որ արժե ուղղել։