> > I committed 54df9353c689434b8bbb4d8b4f816a5f7733a095 which resolves that > > specific > > issue by sending the BOINC daemon a SIGQUIT signal which allows it to > > shutdown > > and clean itself up and it's child processes. It then waits for up to 15 > > seconds > > for /data/data/edu.berkeley.boinc/client/boinc to disappear off the process > > list. > > If the BOINC daemon hasn't gracefully shutdown by then, it sends a SIGKILL. > > I don't have a chance to look into your commit right now, but are you doing > this at > edu.berkeley.boinc.client.Monitor.ClientSetupAsync.startUp() ? That's where > the > SIGKILL happens...
Yes. Here is a link if that is more useful: http://boinc.berkeley.edu/trac/changeset/54df9353c689434b8bbb4d8b4f816a5f7733a095/boinc# > > Now I've run into an issue where the UI gets stuck in a similar cascade > > switching > > between portrait and landscape modes. > > This is odd. UI events should not have an effect on the deamon (except for > the > initial launch of course). The deamon is handled by the Android Service > "edu.berkeley.boinc.client.Monitor". I've broken this off to its own thread. It seems like Android is cycling the service. > Currently, it stops the deamon here in every case and re-starts it. > > If it is possible to detect whether there has been an update to the binaries, > the > re-start could be conditional. We could probably do something with boinc --version and a date time stamp. ----- Rom ---------- From: Joachim Fritzsch [mailto:[email protected]] Sent: Friday, February 15, 2013 4:16 AM To: Rom Walton Cc: BOINC Developers Mailing List Subject: Re: BOINC Daemon Lifecycle on Android Hi Rom, I am impressed by the progress being made during the past week, keep it up! On Fri, Feb 15, 2013 at 4:24 AM, Rom Walton <[email protected]> wrote: Joachim, et al., I have stumbled across some issues with starting up the BOINC daemon on Android and I needed to get some clarification on the various ways Android starts and stops activities and how that relates to the BOINC daemon. My original problem occurred after installing a new version of the BOINC APK via adb. I use the following command: $ adb install -r boinc_7.1.0_arm-android-linux-gnu.apk This in turn caused Android to end the edu.berkeley.boinc process, which was expected. Now when I started the BOINC UI, it was sending a SIGKILL to the daemon so it could update the daemon and re-launch it. At this point things started to go sideways in that the new BOINC was attempting to re-launch the science applications, while the old ones were still executing. While BOINC was trying to figure out what to do next, the UI had a connection failure event and would begin the cycle all over again. At one point there were 12 wrapper applications executing and four science applications. I see. I have missed the science applications in this consideration... I committed 54df9353c689434b8bbb4d8b4f816a5f7733a095 which resolves that specific issue by sending the BOINC daemon a SIGQUIT signal which allows it to shutdown and clean itself up and it's child processes. It then waits for up to 15 seconds for /data/data/edu.berkeley.boinc/client/boinc to disappear off the process list. If the BOINC daemon hasn't gracefully shutdown by then, it sends a SIGKILL. I don't have a chance to look into your commit right now, but are you doing this at edu.berkeley.boinc.client.Monitor.ClientSetupAsync.startUp() ? That's where the SIGKILL happens... Now I've run into an issue where the UI gets stuck in a similar cascade switching between portrait and landscape modes. This is odd. UI events should not have an effect on the deamon (except for the initial launch of course). The deamon is handled by the Android Service "edu.berkeley.boinc.client.Monitor". So my question is, what is the desirable outcome for these startup situations: 1. Launching the UI from the apps screen, when the daemon is not running? start daemon. (precisely, UI starts Service "edu.berkeley.boinc.client.Monitor" which verifies that there is no daemon running and starts it) This case also covers launch after boot. 2. Launching the UI from the apps screen, when the daemon is running? (This seems to cover launching at boot, manual upgrades, automatic upgrades, and whenever Android decides to end various activities.) that's the really tricky one. A few points to keep in mind: a) boot is covered by 1. b) the daemon is launched by the Service, so ending and starting Activities should not influence it. c) The deamon is not subject to either removing the app from the task list nor OOM, not even de-installing the entire application. I could not come up with a way to close the daemon in those cases (see 5.) d) In case of an update, we need to stop the old deamon and start it from the new binaries. Currently, it stops the deamon here in every case and re-starts it. If it is possible to detect whether there has been an update to the binaries, the re-start could be conditional. 3. Switching to the UI from the apps screen? Should not effect the deamon, only creation of UI (implying creation of Service "Monitor") 4. Switching between Landscape and Portrait modes? Should not effect the deamon at all. 5. Should removing the UI from the task list shutdown the daemon? Originally, I wanted to close the daemon here. We wouldn't have this mess if that would work. But unfortunately, neither closing (killing) the UI from task list nor by OOM seems to not be calling any life cycle methods (like onStop - onDestroy) one would expect! So, AFAIK, closing the daemon here is not possible. If anybody comes up with a way how to do that would improve the current implementation a lot! 6. Can we detect if/when Android has killed the daemon or any of its children because of the OOM driver? Should we find a way to have the daemon reschedule for execution later? (http://www.lindusembedded.com/blog/2010/12/07/android-linux-kernel-additions/) I don't think there is, correct me, if I am wrong. Did I miss any other conditions? Thoughts? Bottom line, the root of the problem is the behavior of Android described in 5. - the daemon does not get stopped when the app gets killed by either OOM or by user through task list. ----- Rom _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
