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.
