Перезапускать сервис systemd по строке-триггеру в логе

journalctl -b0 -k -f --grep="amneziawg: wg0: Handshake for peer 4 (185.130.???.???:51820) did not complete after 5 seconds, retrying" | while read _; do systemctl restart awg-quick@wg0.service; done

проверки добавить по вкусу.

Ага, то есть самих встроенных триггеров в systemd нет, но можно использовать опцию -f в journalctl для использования в скриптах? Спасибо, попробую.

Хотя нет, не получится вывод команды journalctl -b 0 -k -f –grep=«amneziawg:» –grep=«did not complete after» всегда будет не пустым, потому что первой строкой всегда будет выводиться

– Logs begin at Sun 2024-09-29 00:45:13 MSK. –

То есть подобный скрипт всегда будет перезапускать сервис

Я бы посмотрел в сторону fail2ban. Он как раз для выполнения действий при появлении строк в логе

а ещё grep это утилита такая ;)

Может все-таки решить это на уровне демона? Грепать логи конечно хорошо и полезно, но имхо это в последнюю очередь.

потому что первой строкой всегда будет выводиться

journalctl --quiet:

Suppresses all informational messages (i.e. «– Journal begins at …», «– Reboot –») <…>

Может все-таки решить это на уровне демона? Грепать логи конечно хорошо и полезно, но имхо это в последнюю очередь.

Вот и я думаю как это реализовать. Наверняка есть некий сокет, через который могжно получать сообщения лога ядра, не задействуя при этом journalctl.

Банальщина: А оно не умеет тупо вываливаться?

Это amneziawg, форк wireguard, ПО для впн. Состоит из модуля ядра amneziawg.ko и 2-х утилит в userspace: awg и awg-quick. Собственно после того как ты запустил впн, он работает, в качестве транспорта используется UDP, состояние канала по умолчанию не отслеживается, но можно добавить опцию, которая будет раз в n секунд слать тестовые пакеты, результат будет писаться в dmesg. Собственно задача создать 2 скрипта:

1. запускается сразу после установления соединения и отслеживает в dmesg сообщение «Receiving handshake response from peer», если оно есть, то добавляет дефроут
2. скрипт работает непрерывно пока запущено соединение и отслеживает в dmesg сообщение «did not complete after», если оно есть, то удаляет дефроут и перезапускает соединение

Я немного не о том. Оно само в случае если условно «не получило н-реплаев» вывалиться? Это самый простой способ по перезапуску получится. Но если не умеет, то традиционно «собаку» над ним повесить и «будет счастье». Собаку не в виде «читаем лог», это немного глупо, в логах много чего может быть или не быть, нас же интересует реальная работоспособность, а не букавки в текстовом файле.

Оно само в случае если условно «не получило н-реплаев» вывалиться? Не-а, я тут попробовал, между 2-х виртуалок (сервер и клиент) канал поднять, даже если ты сервер погасишь, на клиенте канал будет висеть, поэтому нужно что-то накостылить, чтобы он перезапустился или остановился сам. Короче какой совет?

Короче какой совет?

Повесить собаку. Старый добрый безотказный вариант. Точнее в нем тоже могут быть косяки, но это уже отдельные случаи «зависимости от зависимости» и их сюда имхо не стоит приплетать.
В собаке проверяем реальную! работоспособность и если не робит, рестартуем.

Не понимаю я этот жаргон, что значит «повесить собаку»? Какой-то скрипт, запускаемый через cron или скрипт, запускаемый через ExecStart в юните, чтобы он стартовал одновременно с сервисом?

«повесить собаку»

Вотчдог на событие включи.

Довольно странно, что помогает перезапуск интерфейса. У WG же нет состояния. И вообще лучше бы разобраться с причинами проблемы.

Смысл в том, чтобы если пропала связь с сервером, удалить дефроут и регулярно перезапускать сервис пока связь не восстановится.

amneziawg, форк wireguard

Стандартный wg выдаёт инфу о состоянии подключения. Разве у awg нет утилиты, которая даёт инфу о состоянии? Это я к тому, что может и не надо грепать журнал.

Повесить собаку.

Живодёр! Не «повесить», а «натравить». В крайнем случае - «поставить стеречь».

Не понимаю я этот жаргон, что значит «повесить собаку»?

Это от «watchdog».

Какой-то скрипт, запускаемый через cron или скрипт, запускаемый через ExecStart в юните, чтобы он стартовал одновременно с сервисом?

Да, независимая хрень которая будет проверять работоспособность и в случае если не робит, делаем так что бы заробило. Только обращаю внимание, именно независимая хрень! собирать всё в один юнит тоже уже путь к складыванию яиц в одну корзину. Мне для подобных, не требующих мгновенной реакции, случаев пока крона хватает.

перезапускать сервис пока связь не восстановится

Чтобы что? У (A)WG не ни состояния, ни соединения как такового. Если связь восстановится, пакеты снова пойдут. Наверное, перезапуск имеет смысл, если endpoint указан как доменное имя, а не IP, при этом адрес периодически меняется. Других причин я придумать не могу 🤔

Стандартный wg выдаёт инфу о состоянии подключения.

Там нет ни состояния, ни подключения (потому что UDP). Есть интерфейс, по нему ходят пакеты успешно или не очень, вот и всё. Если используется keepalive, то есть некоторое представление о состоянии пира в духе «был жив столько-то секунд назад».

У (A)WG не ни состояния, ни соединения как такового.

Да ну? Заходи кто хочешь, бери чего хочешь.

Если связь восстановится, пакеты снова пойдут.

Як однозначно прозвучало. Вот внатуре пойдут. Попахивает высказыванием учительницы из урпинска из которого она никогда не выезжала.

Других причин я придумать не могу 🤔

Ну и зачем тогда зашли со своим «безусловно авторитетным» мнением?

Стандартный wg выдаёт инфу о состоянии подключения.

Там нет ни состояния, ни подключения (потому что UDP)

И что UDP ?

Да ну?

Ну ты сначала разберись, как работает WG. На официальном сайте всё хорошо описано.

Заходи кто хочешь, бери чего хочешь.

Я не знаю, что означают эти метафоры. Это технический форум, выражайся конкретно.

И что UDP ?

Connectionless. И сам протокол WG тоже не натягивает какого-то стейта поверх (ну, почти 🙃): https://www.wireguard.com/protocol/

In other words, you bring the device up, and everything else is handled for you automatically. You don’t need to worry about asking it to reconnect or disconnect or reinitialize, or anything of that nature.

И это работает именно так, пока данные пиров верны.

Ну ты сначала разберись
На официальном сайте всё хорошо описано

Ясно. Анон был есть и будет аноном, быстро вброшеное не считается вбросом.

Connectionless

И что значит это в вашем понимании?

In other words, you bring the device up, and everything else is handled for you automatically. You don’t need to worry about asking it to reconnect or disconnect or reinitialize, or anything of that nature.

Ещё в конце «Мамой клянусь» не хватает.

Чтобы что?

Чтобы на хосте сеть продолжила работать. Сеть работает по основному каналу (через впн) и резервному каналу (без впн), соответственно два дефроута есть: первый - с меньшей метрикой, второй - с большей. Чтобы сеть продолжила работать, нужно первый дефроут удалить.

Так тебе, наверное, не логи надо парсить, а что-то для мониторинга сети с возможностью выполнять произвольные действия. Насчёт специализированного не подскажу, но из универсальных решений может подойти monit.