Чаму юніт 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, і гэтыя два патрабуюць розных выпраўленняў. Затым дакажыце ўсё гэта халодным загрузам, а не перазапускам службы, бо перазапуск ідзе па сетцы, якая ўжо ўзнятая, і схавае менавіта той дэфект, які вы шукаеце. Паўтарыце гэта са злучэннем, наўмысна запаволеным, і лічыце юніт, які працуе толькі пры хуткай сетцы, усё яшчэ зламаным.