Как правильно сообщить о внезапном завершении другого процесса в Linux?

Я работаю над встроенным решением, в котором работают два приложения: одно — пользовательский интерфейс, а другое — работает в фоновом режиме, предоставляя данные для пользовательского интерфейса.

Недавно я столкнулся с утечкой памяти или подобной ошибкой, из-за которой Linux убивает вторичный процесс, оставляя пользовательский интерфейс в остановленной ситуации, ничего не сообщая пользователю о том, что происходит. Я решил проблему, прочитав файл журнала Linux message и печать программного обеспечения на терминале «Kill -myapp».

Мой вопрос: как я мог заметить такое событие (и другое подобное), происходящее от вторичного программного обеспечения, чтобы я мог правильно сообщить об этом пользователю и зарегистрировать его? Я имею в виду, что легко время от времени заглядывать в «дерево» процесса, чтобы увидеть, запущено ли вторичное приложение, и, если это не так, сообщить «произошло какое-то событие» в пользовательском интерфейсе, и также вероятно, что есть ошибка -система обработчика внутри вторичного приложения, которая заставляет его записывать в файл журнала то, что только что произошло, и заставлять пользовательский интерфейс время от времени читать этот файл для новых записей, но как приложение пользовательского интерфейса может знать более подробно, что происходит в таком большем количестве? внезапные события? (в данном случае «Linux убил процесс», но это может быть «канал сегментации» или любой другой) (и если есть другое, лучшее решение, что это «постоянное чтение файла журнала, созданного вторичным приложением», я лд тоже хотел бы знать)

Примечания: пользовательский интерфейс написан на C++/Qt, а дополнительное приложение — на C. Хотя решение с использованием библиотеки Qt приветствуется, я думаю, что для всего сообщества программистов было бы лучше, если бы было предложено более обобщенное решение.


person Momergil    schedule 14.08.2014    source источник
comment
Прочтите: alexonlinux.com/signal-handling-in-linux Проверка из сторона пользовательского интерфейса тоже может быть умной, потому что обработчик сигнала может не запускаться во всех случаях, когда процесс убит.   -  person eerorika    schedule 14.08.2014


Ответы (1)


Вы можете создать обработчик сигналов POSIX, таких как SIGKILL, во внутреннем процессе и уведомить пользовательский интерфейс, используя, например, другой сигнал с помощью поставить в очередь. Любой механизм IPC должен работать, если он асинхронно безопасен. Узнайте больше о сигналах: руководство и руководство

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

Что касается лучшего способа проверить, жив ли процесс по сравнению с чтением файла журнала: Проверить, существует ли процесс, учитывая его pid

person eerorika    schedule 14.08.2014
comment
(никогда не думали о смене имени пользователя? :P) спасибо за ответ! Вопрос: в каких случаях обработчик может не запуститься? Q2: Я знаю, как писать обработчики сигналов внутри приложения, в котором может возникнуть ошибка, но как мне писать в другом процессе, отличном от того, в котором возникает ошибка? Или вы действительно хотите написать обработчик первым способом? - person Momergil; 14.08.2014
comment
Я думаю, что мое имя броское :) Q: Ну, возможно, я был слишком осторожен с этим советом. Возможно какая-то проблема в самой ОС. В основном я думал о покрытии пользовательского интерфейса на случай, если ваш обработчик не сможет сделать то, что должен (например, из-за ошибки). - person eerorika; 14.08.2014
comment
Q2: Да, первый способ. Отправьте сигнал (sigqueue) процессу пользовательского интерфейса из обработчика сигнала в завершающем бэкэнде. Или используйте любой другой механизм IPC - person eerorika; 14.08.2014