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

0

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

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

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

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

  • 2
    Читайте: alexonlinux.com/signal-handling-in-linux Проверка со стороны пользовательского интерфейса также может быть разумной, поскольку обработчик сигнала может не запуститься во всех случаях, когда процесс прерывается.
Теги:
error-handling
qt
runtime-error

1 ответ

0

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

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

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

  • 1
    (никогда не думал об изменении вашего имени пользователя?: P) спасибо за ответ! Q: в каких случаях обработчик может не запуститься? Q2: я знаю, как писать обработчики сигналов из приложения, где может возникнуть ошибка, но как было бы писать в процессе, отличном от того, в котором происходит ошибка? Или вы на самом деле хотите написать обработчик первым способом?
  • 1
    Я думаю, что меня зовут броско :) Q: Ну, возможно, я был слишком осторожен с этим советом. Может быть, какая-то проблема в самой ОС. В основном я думал о покрытии пользовательского интерфейса на случай, если ваш обработчик не сможет сделать то, что должен (например, из-за ошибки).
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню