Bug #1228
closed
Appmgr does not restart launcher app when it exits.
100%
Description
In AutoKiosk the launcher (which is configured to be videofe) can exit if the user hits ESC too fast. When the launcher exits, appmgr does not restart it.
In waiter.c:waiter() a test should be done on the returned PID, re: localPID, to see if it matches launcherPID, which is saved in queueProcessor.c. If it does match, then startLauncher can be called again.
Updated by Hammel 12 days ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
Fix is coded but needs testing on hardware, specifically the AutoKiosk where the launcher can be exited using ESC multiple times.
Be sure to enable debug for appmgr and launcher on the test system and tail the appmgr log before trying to kill the launcher.
I might need to modify vfe to only scan usb and not smb to be able to test this with networking connected.
Updated by Hammel 10 days ago
- % Done changed from 50 to 60
Didn't work again, but now I know why.
The call to startLauncher() queues a message to start a new app. The message type is MT_START and the handler for this calls startNew().
startNew() will save the launcherPID only if the command is "launcher". But for AutoKiosk the command is "videofe".
What needs to changes is that startLauncher() needs to queue a message with a TAG of "LAUNCHER" so that startNew() can examine this and, if the tag is not NULL and is "LAUNCHER" then it saves the pid. This test is done instead of checking if the command to run in "launcher".
With this fix the LauncherPID should properly be set so it can be caught on exit and restarted, no matter what the launcher app really is.
Updated by Hammel 8 days ago
Still doesn't work, but this time because the login in waiter.c:waiter() is wrong.
This thread waits on apps to exit. Right now, it also needs to have a semaphore notification before it starts to wait on a child process to exit. That's so the thread can exit. The thread should start waiting for ANY child process launched by appmgr to exit immediately after the thread is started. Breaking out of the thread can be done some other way. The simplest way to do that is have appmgr's waiter shutdown function kill any processes it thinks are still running. That should allow the waiter() loop to break out of the waitpid(), where the shutdown test can be done and the loop exited, or simply let the waitpid reap all child processes as they are shutdown.
When waitpid() returns the returned PID can be tested against the launcherPID to see if the launcher needs to be restarted. Otherwise, it just handles the closed app as usual by notifying the launcher of the apps exit (which is just a simple SIGUSR1 to the launcher app).
This can also test if the returned PID is the last app started, but this isn't really necessary.
Updated by Hammel 8 days ago
- % Done changed from 70 to 80
I refactored process handling into two threads. One that handles the launcher app and one that handles apps that the launcher requests.
I've tested this on AutoKiosk, using the ESC key that kills omxplayer, and it seems to work. When videofe exits because omxplayer exited, appmgr sees this and restart videofe (because it's the launcher app for AutoKiosk).
Debug shows that the processing of the restart is apparently correct. I don't see any problems with it. The videofe app is definitely restarted correctly.
This update needs to be tested on other systems to make sure it didn't break general application handling from the launcher.