0

I'm working on a embedded solution where two apps are working: one is the user interface and the other runs in the background providing data for the UI.

Recently I came across with a memory leak or similar error that is making Linux kill the secondary process, leaving the UI in a stopped situation without telling anything for the user about what is going on. I reached the problem by reading Linux's message log file and the software's print on terminal "Kill -myapp".

My question is: how could I notice such an event (and other similar) coming from the secondary software so I could properly report it to the user and log it? I mean, it's easy to have a look time to time in the process 'tree' to see if the secondary app is running and, if it's not, report a "some event happened" in the UI and it's also plausible to have a error-handler system inside the secondary app that makes it write in a log file what just happened and make the UI read that file for new entries from time to time, but how could the UI app knows with better details what is going on in such more abrupt events? (in this case, "Linux killed process", but it could be a "segmentation pipe" or any other) (and if there is another, better solution that this "constant read a log file produced by the secondary app", I'ld also like to know)

Notes: the UI is written in C++/Qt and the secondary app is in C. Although a solution using the Qt library would be welcomed, I think it would be better for the entire programming community if a more generalized solution was given.

Momergil
  • 2,213
  • 5
  • 29
  • 59
  • 2
    Read up: http://www.alexonlinux.com/signal-handling-in-linux Checking from the ui side too may be smart too because a signal handler may not get to run in all cases where process is killed. – eerorika Aug 14 '14 at 12:23

1 Answers1

0

You can create a signal handler for POSIX signals such as SIGKILL in the backend process and notify the ui using for example another signal with sigqueue. Any IPC mechanism should work, as long as it's async safe. Read more about signals: tutorial and manual

It may still be a good idea to check from the ui side periodically because the handler might not succeed.

As for a better way to check if process is alive compared to reading the log file: Check if process exists given its pid

Community
  • 1
  • 1
eerorika
  • 232,697
  • 12
  • 197
  • 326
  • 1
    (never thought about changing your user name? :P) thanks for the reply! Q: in which cases the handler may not get to run? Q2: I know how to write signal handlers from inside the app where the error may occur, but how would it be to write in a different process than the one the error is occurring? Or you actually mean to write the handler the first way? – Momergil Aug 14 '14 at 12:53
  • 1
    I think my name is catchy :) Q: Well, I may have been over overcautious with that advice. Maybe some problem in OS itself. Mostly I was thinking of covering the ui in case your handler fails to do what it's supposed to (due to bug for example). – eerorika Aug 14 '14 at 13:08
  • Q2: Yes, the first way. Send a signal (sigqueue) to the ui process from the signal handler in the terminating backend. Or use any other IPC mechanism – eerorika Aug 14 '14 at 13:11