Защо юнитът на VPN стартира преди мрежата и после умира

Заредете машината, влезте и разберете, че тунелът е тръгнал и е умрял няколко секунди по-късно. Профилът беше наред, сертификатът беше наред и единствената останала следа е журналът от това зареждане. Обикновено се е случило състезание: юнитът е стартирал, преди машината да има адрес, а редът, който е обявил, не е означавал това, на което изглежда. Всичко по-долу е за това да докажете състезанието от доказателства и да го затворите правилно.

Целта е място за среща, не управител

network-online.target не знае какво е мрежа. Това е точка за координация, която събира онази услуга, която трябва да забави стартирането, докато връзката стане използваема, и прехвърля дефиницията на онзи мрежов управител, който притежава машината. На повечето настолни компютри и сървъри това означава услуга за изчакване, доставена от NetworkManager или от systemd-networkd. Не включете нито една и целта няма какво да чака, затова тя се завършва в момента, в който нещо я дръпне, което може да е доста преди DHCP да отговори. Редът за подредба в юнита ви беше честен и въпреки това безполезен.

Първият въпрос следователно не е какво обявява юнитът ви. А дали нещо на тази машина всъщност изчаква.

Четете последното зареждане, не файла на юнита

Файловете на юнитите описват намерение, а журналът описва какво се е случило. Поискайте само това зареждане, с монотонни времеви отпечатъци, така че всяко съобщение да стои на един часовник. После намерете два реда: момента, в който юнитът на тунела е започнал да стартира, и момента, в който се е появил адресът или е приключила услугата за изчакване. Подредете тези две числа и състезанието или се потвърждава, или се изключва.

Изгледът на зависимостите го потвърждава. Ако критична верига за юнита на тунела не съдържа услуга за изчакване, нищо по този път не е забавило стартирането и целта не е свършила работата, която сте предполагали. Два изгледа, едно заключение.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Добавете изчакването, после повторението

Използвайте drop-in, вместо да редактирате пакетиран юнит, за да не изхвърли актуализация на пакета промяната безшумно. Важни са две директиви: юнитът трябва да е подреден след целта и трябва да дръпне целта в същата транзакция. Подредбата сама по себе си не призовава целта; желанието го прави.

Пакетираният юнит на клиента OpenVPN вече носи и двете. Ръчно написаните юнити обикновено носят едно или нито едно, което си струва да се провери, преди да добавите нещо.

[Service]
Restart=on-failure
RestartSec=15

Защо фиксираното заспиване е капан

Заспиване в ExecStartPre изглежда като поправка на подредбата и се държи като забавяне с допълнителни стъпки. То забавя всяко зареждане, включително здравите, и пак губи, когато връзката отнеме повече време от числото, което сте избрали.

По-лошо, то скрива дали услугата за изчакване работи, затова следващият отказ изглежда като чисто нова проблема, а не същата с различно време. Кратко забавяне при рестартиране е по-добрият инструмент: не струва нищо при здраво зареждане и превръща загубеното състезание в още един опит. Дръжте интервала скромен и оставете юнита да успее. Ако се рестартира вечно, профилът е счупен и никакво повторение няма да промени това, затова четете журнала, вместо да вдигате интервала.

Когато редът е правилен, а имената пак се провалят

Активен юнит с маршрут за тунела означава, че подредбата е свършила работата си и оставащата повреда е един слой по-горе. Обичайната форма е настройка на резолвер, приложена от up скрипта на тунела, преди връзката или резолверът да е бил готов да я задържи. Сравнете състоянието на резолвера по време на отказа със състоянието след рестарт на юнита на тунела.

Ако рестартът поправя търсенето, имате дефект в подредбата на стартирането, а не грешен DNS сървър, и тези две се нуждаят от различни поправки. После докажете цялото нещо със студено зареждане, а не с рестарт на услугата, защото рестартът работи върху вече вдигната мрежа и ще скрие точно дефекта, който гоните. Повторете го с умишлено бавна връзка и считайте юнит, който работи само при бърза мрежа, за все още счупен.