13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|||||||||||
1 | |||||||||||
Watchdog на основе таймеров POSIX29.12.2019, 22:41. Показов 7534. Ответов 65
Метки нет (Все метки)
Добрый день, решил написать watchdog для сервера и чтобы не тратить зазря процессрное время решил реализовать это на основе таймеров POSIX, а не через создание отдельного потока.
Почитал документацию и остались некоторые вопросы: 1)Как должна быть организована проверка что сигнал пришёл от созданного мною таймера, а не от стороннего приложения ? Сечас в обработчик приходит _si->si_pid == 0 2)Как сделать сброс таймера т.е. чтоб начинал считать по новому ? это всётаки watchdog. 3)Как подружить мой watchdog и std::getline(cin, str_command ? 4)Надо ли вызывать предыдущие обработчики если я их не создавал ? 5)Надо ли делать задержку после вызова timer_settime ? 6)Какой тип таймера выбрать ? CLOCK_REALTIME меня смущает что ктото мжет перевести время. код внизу watchdog.cpp
0
|
29.12.2019, 22:41 | |
Ответы с готовыми решениями:
65
WatchDog Пробуждение по watchdog WatchDog в Python Watchdog из Arduino |
18844 / 9843 / 2408
Регистрация: 30.01.2014
Сообщений: 17,285
|
|
31.12.2019, 21:51 | 21 |
timerfd - это точно такой же объект ядра.
Обработчик сигнала, естественно, ни в каком потоке ядра не выполняется. Что толку, если вы из него не сможете безопасно сделать то, что нужно? Давайте вы грамотно сформулируете задачи для вашего watchdog и выложите здесь, а то как бы не оказалось, что вас только аппаратный watchdog устроил бы. Они взялись от того, что сигнал прерывает выполнение программы в произвольном месте.
0
|
13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|
31.12.2019, 21:59 [ТС] | 22 |
DrOffset у меня нет конкретных требований к watchdog потомучто я не системный программист Linux, но мне кажется таймер POSIX более живучим инструментом чем timerfd. Если Вы сможете объяснить разницу между ними почему одному можно по полной использовать все фишки плюсов, а для другого можно только из списка выше то будет здорово. Если Вам кажется что они равнозначности в части применения для watchdog то тоже было бы интересно узнать почему.
0
|
18844 / 9843 / 2408
Регистрация: 30.01.2014
Сообщений: 17,285
|
|
31.12.2019, 22:09 | 23 |
Тогда ваша уверенность кажется мне необоснованной.
Потому что обработчик таймера при реализации через сигналы получает те же ограничения, которые получает сам обработчик сигнала. Если поток, в котором будет выполнятся мониторинг timerfd, не должен зависать, то в ваших силах сделать так, чтобы оно так и было. Если же система по каким-то причинам решит "угробить" весь процесс, то и обработчик сигнала вам не поможет. Они не равнозначны - это разные подходы. Но исходя из того, что вы показали выше, таймеры ASIO или непосредственно сам timerfd вам подходит больше. Я вижу, что вы пытались написать код, который исполняет callback в контексте обработчика таймера. Если этот обработчик - обработчик сигнала, то сделать это в общем виде невозможно. Т.к. ваш callback начинает испытывать те же ограничения, что и сам обработчик сигнала. Или вы формулируете требования, из которых становится понятно, что данные ограничения - не помеха, или задача решения не имеет в такой постановке.
0
|
13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|
31.12.2019, 22:23 [ТС] | 24 |
У меня нету никакой увереннсти. Это я линюсь писать оговорки :-) "что мне так кажется".
Ну допустим я пишу код второпях или решил приколоться и запустил timerfd в коде нового, а не основного потока. Как я понимаю обработчик будет тоже вызван в коде нового потока и этот поток завис наглухо. Да callback там потомучто watchdog не в курсе tid-ов запушенных потоков, а задача у колбека банальная pthread_kill(_current_tid) ну и флажк атомарный выставить для основного потока. Вообще хочеться watchdog сделать как "библиотечный" чтоб был на все случаи жизни, а не только для конкретного приложения.
0
|
18844 / 9843 / 2408
Регистрация: 30.01.2014
Сообщений: 17,285
|
|
31.12.2019, 22:25 | 25 |
Мониторинг timerfd выполняется тем же способом, которым вы делаете мониторинг, например, сокетов. При срабатывании select\poll\epoll для такого дескриптора, у вас будет возможность запустить обработчик в контексте одного из потоков приложения, естественно при этом нам доступны все стандартные возможности, потому что программа находится в корректном состоянии.
Добавлено через 2 минуты С чего бы ему зависнуть? Да и где будет вызван обработчик (и будет ли вызван вообще) решаете вы. Ну и если писать код второпях, то какой подход не используй - все равно фигня получится. Давайте все-таки нормально делать. Вы опишите пожалуйста чего хотите делать своим watchdog`ом, а я уж как-нибудь постараюсь вас не обидеть и порекомендовать приемлемое решение.
0
|
13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|
31.12.2019, 22:30 [ТС] | 26 |
Я хочу поставить вопрос с ног на голову. Вот есть таймер POSIX. Для каких случаев он лучше timerfd ? Кгда наоборот я уже понял.
0
|
18844 / 9843 / 2408
Регистрация: 30.01.2014
Сообщений: 17,285
|
|
31.12.2019, 22:51 | 27 |
squareroot,
* когда timerfd не поддерживается. * когда нам нужна POSIX-переносимость (например на solaris или freebsd) (*) * когда у нас уже есть приложение, архитектура которого построена на обработке сигналов * когда нам нужно открывать огромное количество файловых дескрипторов и занимать под это дело таймер - роскошь. ___________ (*) тщательно проверив при этом реализацию, совместимость с POSIX для ОС - это не догма Про стабильность приложения ничего не пишу, потому что считаю, что оба подхода позволят достичь любой возможной на уровне пользователя стабильности приложения. Хотел еще вам порекомендовать посмотреть на watchdog daemon в linux. И на Linux Watchdog Driver API: https://www.kernel.org/doc/htm... g-api.html
1
|
13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|
31.12.2019, 22:56 [ТС] | 28 |
Во, вот за ссылку на апи Linux Watchdog Driver API спасибо. Но я раньше не наблюдал в ответах. Но Watchdog линуксовый вроде слишком суровый, он ребутит всю систему или я не прав ?
0
|
18844 / 9843 / 2408
Регистрация: 30.01.2014
Сообщений: 17,285
|
|
31.12.2019, 22:57 | 29 |
Да, именно так. Но вы выше ясно дали понять, что опасаетесь любых проблем. Так если у вас настолько все серьезно, то проще перезагрузить машину.
0
|
13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|
31.12.2019, 23:16 [ТС] | 30 |
Ну в дополнении к пользвательскому вотчдогу это очень замечательно будет.
Добавлено через 6 минут Только запускать надо будет от рута скорей всего.
0
|
18844 / 9843 / 2408
Регистрация: 30.01.2014
Сообщений: 17,285
|
|
31.12.2019, 23:21 | 31 |
Если вы все равно пишете демона, то это не проблема же?
Да и для юзерспейса есть watchdog daemon, который предоставляет эту функциональность для произвольных приложений.
0
|
13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|
31.12.2019, 23:25 [ТС] | 32 |
До написания демона у меня не скоро руки дойдут. Этому вотчдоку сильно не хватает потокобезопаснсти, но мьютекс не хочу использовать. Надо щас будет копать в части locck free структур или спинлок запилить.
0
|
18844 / 9843 / 2408
Регистрация: 30.01.2014
Сообщений: 17,285
|
|
31.12.2019, 23:29 | 33 |
Я так и не смог от вас добиться формулировки его задач
Ладно. Дело ваше. Может через годик-два вспомните мои слова и совсем по другому на них посмотрите. Добавлено через 16 секунд С наступающим. Засим я отчаливаю.
0
|
13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|
31.12.2019, 23:34 [ТС] | 34 |
0
|
13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|
02.01.2020, 03:40 [ТС] | 35 |
Добрый день всем. Остались некоторые вопросы. Самый насущный: Почему у меня timer_delete всё время возвращает код ошибки ? Как правильно пользоваться этой функцией, в случае когда надо остановить таймер ?
0
|
13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|
08.01.2020, 03:30 [ТС] | 36 |
Только щас понял что таймера asio не получится нормально сбрасывать. Они всёравно будут вызывать обработчик при отмене.
Да, можно конечно по флагй отследить что это именно отмена, но нехорошо всёравно. Добавлено через 1 час 19 минут Всё, теперь окончательно стало понятно что boost::asio::deadline_timer не годится для watcdog-а так требуется ожидание через io_service::run или поллинг io_service:oll
0
|
18844 / 9843 / 2408
Регистрация: 30.01.2014
Сообщений: 17,285
|
|
08.01.2020, 10:51 | 37 |
0
|
13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|
08.01.2020, 12:00 [ТС] | 38 |
Он ничем не помешает, но мне нужен таймер а не счётчик. В бусте нету таймеров, а есть счётчики.
Таймер это когда запустил и забыл. Я не могу использовать основной поток для периодического опроса, и если надо создавать отдельный поток, для опроса, то это лажа. Такое решение мне изначально было неприемлемо.
0
|
18844 / 9843 / 2408
Регистрация: 30.01.2014
Сообщений: 17,285
|
|
08.01.2020, 12:11 | 39 |
Если вы хотите из обработчика таймера делать что-то более сложное, то отдельный поток (а лучше процесс) вам все равно придется делать.
Поэтому я вас просил сформулировать требования к решению.
0
|
13 / 13 / 1
Регистрация: 19.10.2019
Сообщений: 607
|
|
08.01.2020, 12:15 [ТС] | 40 |
Можно и не сложное, но мне нужен кроссплатформенный таймер без дополнительных потоков. Я писал об этом ранее.
Я сформулировал ранее, что мне нужен таймер без дополнительных потоков.
0
|
08.01.2020, 12:15 | |
08.01.2020, 12:15 | |
Помогаю со студенческими работами здесь
40
Внешний WAtchdog AvrSudio и watchdog Analog Watchdog (AWD) Cortex m0 и watchdog таймер Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |