Joachim,
It appears that the service monitor it being restarted when I switch my
tablet from portrait mode to landscape mode. Sometime after that
network communication fails and things get stuck in a loop.
Shouldn't the service clean-up/abort its background threads when it is
restarted?
----- Rom
Logcat out of the transition:
02-15 09:51:33.519: D/ClientMonitorAsync-doInBackground(3057): monitor
loop...
02-15 09:51:33.549: D/ClientStatus(3057): parsing results: computing:
false30 - network: false20
02-15 09:51:33.559: D/StatusActivity-localClientStatusRecNoisy(3057):
received action edu.berkeley.boinc.clientstatuschange
02-15 09:51:33.559: D/MainActivity-clientstatuschange(3057): received
02-15 09:51:33.559: D/MainActivity(3057): determineStatus() old
clientSetupStatus: 1 - newStatus: 1
02-15 09:51:36.219: I/InputReader(479): Reconfiguring input devices.
changes=0x00000004
02-15 09:51:36.229: I/InputReader(479): Device reconfigured: id=2,
name='elan-touchscreen', size 800x1280, orientation 1, mode 1, display
id 0
02-15 09:51:36.229: I/ActivityManager(479): Config changes=1480 {1.0
310mcc?mnc en_US ldltr sw600dp w961dp h528dp 213dpi lrg land finger
-keyb/v/h -nav/h s.6}
02-15 09:51:36.279: D/MainActivity(3057): onPause
02-15 09:51:36.279: D/StatusActivity-onPause(3057): remove receiver
02-15 09:51:36.299: D/MainActivity(3057): onDestroy
02-15 09:51:36.309: D/dalvikvm(3057): GC_CONCURRENT freed 400K, 8% free
7958K/8572K, paused 7ms+5ms, total 42ms
02-15 09:51:36.379: D/MainActivity(3057): onCreate
02-15 09:51:36.459: D/MainActivity(3057): tab layout setup done
02-15 09:51:36.469: D/MainActivity(3057): onResume
02-15 09:51:36.469: D/StatusActivity-onResume(3057): register receiver
02-15 09:51:36.479: D/BOINC Client Monitor Service(3057): onDestroy()
02-15 09:51:36.479: D/ShutdownClientAsync(3057): doInBackground
02-15 09:51:36.519: D/dalvikvm(3057): GC_FOR_ALLOC freed 154K, 6% free
8124K/8572K, paused 18ms, total 18ms
02-15 09:51:36.589: D/dalvikvm(3057): GC_FOR_ALLOC freed 46K, 6% free
8144K/8608K, paused 28ms, total 28ms
02-15 09:51:36.589: I/dalvikvm-heap(3057): Grow heap (frag case) to
8.324MB for 262160-byte allocation
02-15 09:51:36.609: D/dalvikvm(3057): GC_FOR_ALLOC freed 196K, 8% free
8204K/8868K, paused 26ms, total 26ms
02-15 09:51:36.609: D/BOINC Client Monitor Service(3057): onCreate()
02-15 09:51:36.609: D/AppPreferences(3057): appPrefs read
successful.false
02-15 09:51:36.619: D/BOINC Client Monitor Service(3057): asynchronous
monitor started!
02-15 09:51:36.619: D/ClientMonitorAsync-doInBackground(3057): monitor
loop...
Network communicaton failure:
02-15 09:51:39.659: D/ClientSetupAsync-onProgressUpdate(3057): connect
client.
02-15 09:51:39.669: W/RpcClient(3057): connect failure
02-15 09:51:39.669: W/RpcClient(3057): java.net.ConnectException: failed
to connect to /127.0.0.1 (port 31416) after 30000ms: isConnected failed:
ECONNREFUSED (Connection refused)
02-15 09:51:39.669: W/RpcClient(3057): at
libcore.io.IoBridge.isConnected(IoBridge.java:224)
02-15 09:51:39.669: W/RpcClient(3057): at
libcore.io.IoBridge.connectErrno(IoBridge.java:161)
02-15 09:51:39.669: W/RpcClient(3057): at
libcore.io.IoBridge.connect(IoBridge.java:112)
02-15 09:51:39.669: W/RpcClient(3057): at
java.net.PlainSocketImpl.connect(PlainSocketImpl.java:192)
02-15 09:51:39.669: W/RpcClient(3057): at
java.net.PlainSocketImpl.connect(PlainSocketImpl.java:459)
02-15 09:51:39.669: W/RpcClient(3057): at
java.net.Socket.connect(Socket.java:842)
02-15 09:51:39.669: W/RpcClient(3057): at
edu.berkeley.boinc.rpc.RpcClient.open(RpcClient.java:172)
02-15 09:51:39.669: W/RpcClient(3057): at
edu.berkeley.boinc.client.Monitor$ClientSetupAsync.connect(Monitor.java:
699)
02-15 09:51:39.669: W/RpcClient(3057): at
edu.berkeley.boinc.client.Monitor$ClientSetupAsync.connectClient(Monitor
.java:557)
02-15 09:51:39.669: W/RpcClient(3057): at
edu.berkeley.boinc.client.Monitor$ClientSetupAsync.startUp(Monitor.java:
540)
02-15 09:51:39.669: W/RpcClient(3057): at
edu.berkeley.boinc.client.Monitor$ClientSetupAsync.doInBackground(Monito
r.java:473)
02-15 09:51:39.669: W/RpcClient(3057): at
edu.berkeley.boinc.client.Monitor$ClientSetupAsync.doInBackground(Monito
r.java:1)
02-15 09:51:39.669: W/RpcClient(3057): at
android.os.AsyncTask$2.call(AsyncTask.java:287)
02-15 09:51:39.669: W/RpcClient(3057): at
java.util.concurrent.FutureTask.run(FutureTask.java:234)
02-15 09:51:39.669: W/RpcClient(3057): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
a:1080)
02-15 09:51:39.669: W/RpcClient(3057): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.ja
va:573)
02-15 09:51:39.669: W/RpcClient(3057): at
java.lang.Thread.run(Thread.java:856)
02-15 09:51:39.669: W/RpcClient(3057): Caused by:
libcore.io.ErrnoException: isConnected failed: ECONNREFUSED (Connection
refused)
02-15 09:51:39.669: W/RpcClient(3057): at
libcore.io.IoBridge.isConnected(IoBridge.java:208)
02-15 09:51:39.669: W/RpcClient(3057): ... 16 more
02-15 09:51:39.669: D/ClientSetupAsync-onProgressUpdate(3057): socket
connection failed!
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-addi
tions/)
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.
