LINUX.ORG.RU

Постоянная работа приложения на С

 , ,


2

4

Интересует вопрос. Есть программа. В функции main() выполняется код. Как реализовать так что бы программа работала постоянно. Она прослушивает пакеты через libpcap. Ну что то вроде как демон. Не знаю как реализовывать это на С/C++ т.к я начинающий. Заранее благодарен за подсказки или помощь.

Ответ на: комментарий от vodz

Неужели вы не чувствуете, что вот такие высказывания вас и выдают, стоит только нарваться на того, кто знает и спросит объяснить, когда наступает этот случай? :)

когда приехало привет от терминала ? да легко, хоть и редко. это из серии когда иногда malloc() на NULL не проверяют - а зачем ж ? ведь sbrk() или mmap() всегда что то хорошее вернут да ? гипотечиски брякнете терминал при запуске, либо отвалится он по telnet например.

Ибо если уж сам fork завершился успешно, то пусть потомок сам и жалуется в лог, что у него пошло не так.

это не всегда так, fork() конечно дорогая операция, но не факт что на первом вызове чего либо по ошибке что то не отвалится где нибудь.

Родителю=копии не возможно толком узнать проблемы сына, так как он имеет после fork-а другое адресное пространство, хоть и на первых порах и копию.

это тут совсем не при как.

Ибо если уж сам fork завершился успешно, то пусть потомок сам и жалуется в лог, что у него пошло не так

особенно когда надо куда то еще сообщить что пошло не так да. особенно он клевски пожалуется в случае segfault. поэтому после проверки всяких там конфигураций лучше отследить на первых порах что и как, чтобы сообщений respawn своему что пошло так или не так и waitpid ему в помощь

Увы, полностью мимо.

да, ну я уже написал там где то сверху.

alwayslate ★★
()
Ответ на: комментарий от alwayslate

когда приехало привет от терминала ? да легко, хоть и редко. это из серии

Тяжёлый случай... Это вы детям можете объяснять «из серии». Тут это не прокатит. Так и будет записано - ответа не знает.

чего либо по ошибке что то не отвалится где нибудь.

Тогда это будет не демон, а монитор над демоном. Если уж говорить о linux-специфике, то его даже уже написали - systemd называется.

vodz ★★★★★
()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от vodz

Тяжёлый случай... Это вы детям можете объяснять «из серии». Тут это не прокатит. Так и будет записано - ответа не знает.

дада ok, мне лень спорить.

Тогда это будет не демон, а монитор над демоном. Если уж говорить о linux-специфике, то его даже уже написали - systemd называется.

systemd есть не везде и его реализация с system() и прочими радостями ... это раз.

два - я уже сказал что можно было лишнее убрать из моего примера, суть моего посыла вообще была в том что не делать как тут многие сказали сразу while(1) и тд, а делать правильно, с форками и прочими радостями. Кстати, в этом вашем systemd это приветсвуется да, можно не делать и плевать что это не будет нормально работать вне systemd.

и таки я признал еще за несколько ответов что оно тут не к месту, а у вас началось - что зачем и тд. конечно принимать всех людей за идиотов это выживательная стратегия в каком то смысле, на каком то уровне развития - поэтому ok, дальше лень спорить на форуме.

alwayslate ★★
()
Ответ на: комментарий от alwayslate

в этом вашем systemd

Вах, с чего вы взяли, что я апологет systemd? :)) Это я же пробный камень кинул, вдруг вы приверженец модно-молодёжно и приятно будет, а нет - так просто пример «из серии»...

всех людей за идиотов

Это у вас обида говорит. Ибо всё и было именно вот для этого:

что можно было лишнее убрать из моего примера

то есть и убирал - закрытие всех дескрипторов и неверные signal().

А срач развели именно вы, что бросились возражать без знаний.

vodz ★★★★★
()
Ответ на: комментарий от vodz

Вах, с чего вы взяли, что я апологет systemd? :)) Это я же пробный камень кинул, вдруг вы приверженец модно-молодёжно и приятно будет, а нет - так просто пример «из серии»...

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

Это у вас обида говорит.

я странный человек - не обижаюсь никогда ни на что и ни на кого, жизненное кредо если хотите.

Ибо всё и было именно вот для этого:

потерял я тут цепочку.

А срач развели именно вы, что бросились возражать без знаний.

верьте нет, знаний хватает, может что из них уже затухло и не актуально, но будучи еще senior sw dev реализовывал и posix сверху не posix системы, и много что интерестного. но вы не поняли (или я хреново пояснил, допускаю - свитчится с 3х языков сложно и мне до гения как до китая пешком)  — понимание что происходит, когда и тд оно есть, но я не за это говорил, а за то что не всегда (далеко) daemon() достаточен. всего то да.

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

alwayslate ★★
()
Ответ на: комментарий от alwayslate

то что не всегда (далеко) daemon() достаточен. всего то да.

IMHO, у daemon() ровно один недостаток, это bsd, и потом linux-овая специфика, а не стандартная libc. Интерфейс у этой функции так себе, оно и понятно, не гении проектировали. Закрытие всех дескрипторов действительно иногда практикуется, так что отдельным флагом в daemon() не помешало б, но отдельным же!

А про sigchld — вы не растраивайтесь. Хай насчёт зомби-процессов в unix-е никогда не умрёт, как и зомби :) Беда именно в том, что с пониманием что именно править туго у даже вполне признанных Unix (обычно не системных) программистов.

Всё остальное пришлось скипнуть, так как уже совсем на около личную переписку похоже.

vodz ★★★★★
()
Ответ на: комментарий от vodz

MHO, у daemon() ровно один недостаток, это bsd, и потом linux-овая специфика, а не стандартная libc. Интерфейс у этой функции так себе, оно и понятно, не гении проектировали. Закрытие всех дескрипторов действительно иногда практикуется, так что отдельным флагом в daemon() не помешало б, но отдельным же!

ну, тут проблема в том что он слишком common, то есть шаг туда шаг сюда и расстрел.

А про sigchld — вы не растраивайтесь.

как минимум по этому поводу я спокоен.

Хай насчёт зомби-процессов в unix-е никогда не умрёт, как и зомби :)

unix сейчас это слишком что то не до конца понятное. но да это уже философия.

Беда именно в том, что с пониманием что именно править туго у даже вполне признанных Unix (обычно не системных) программистов.

беда на самом деле в POSIX - правда, когда начинаются микроядра и прочие радости там начинаются проблемы. то есть POSIX больше для монолита, ну или как костылить, тк если «классически» в тех же тру микроядрах pid 1 не есть init, который должен хендлить остальных.

Всё остальное пришлось скипнуть, так как уже совсем на около личную переписку похоже.

ну вот и порешили да.

alwayslate ★★
()
Ответ на: комментарий от alwayslate

в тех же тру микроядрах pid 1 не есть init, который должен хендлить остальных.

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

vodz ★★★★★
()
Ответ на: комментарий от vodz

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

это уже out of scope этого треда. а так в микроядре надо много чего чтобы запуститься и первым пидом может быть foo а может bar - там сложности с дизайном.

alwayslate ★★
()
Ответ на: комментарий от alwayslate

не будет нормально работать вне systemd.

runit, supervisord, daemontools, и т. д. systemd хотя бы Type=forking умеет мониторить, а в runit без костылей форкающееся говно не запустить.

anonymous
()
Ответ на: комментарий от anonymous

systemd хотя бы Type=forking умеет мониторить

да гавно этот ваш сустемдик уже сто раз обсасывали.

форкающееся говно

то есть unix way это гавно, надо новый мир построить из костылей прямиком из win world ? круто да.

alwayslate ★★
()
Ответ на: комментарий от alwayslate

Вантузятники — они такие. Эти уроды в любую дыру лезут со своей ацефалией!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.