Adding a non-returning command to a shell will trigger terminated timeout exception, even though it's not actually terminated.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. make a custom command:

            Command command = new Command(0, "tcpdump -nw /sdcard/test.cap") {

                @Override
                public void commandOutput(int id, String line)
                {
                }

                @Override
                public void commandCompleted(int id, int exitcode) {
                }

                @Override
                public void commandTerminated(int id, String reason) {
                    Toast.makeText(getApplicationContext(), "TCPdump was terminated. Reason:\n" + reason, Toast.LENGTH_LONG).show();
                }

            };

2. Make sure we don't have a custom shell running, then make custom shell (also 
happens with root shell btw), with infinite timeout (or say 99999999), and run 
it:

RootTools.closeCustomShell();
RootTools.getCustomShell("su", 0).add(command);

3. and wait..

What is the expected output? What do you see instead?

- Expected output: to not have the commandTerminated handler be called with a 
Timeout Exception.

- seen instead: the commandTerminated handler was called with a Timeout 
Exception. Exactly 20 seconds after the above code was called.

What is more, the tcpdump process wasn't actually killed:

# before running the above code:
shell@android:/ # ps | grep tcpdump
<no output>

# running code, before timeout exception:
root      31082 31072 3248   876   c0435ed4 40124b2c S 
/data/data/net.teclo.NeTrace/app_bins/tcpdump

# running code, after timeout exception:
shell@android:/ # ps | grep tcpdump
root      31082 31072 3248   876   c0435ed4 40124b2c S 
/data/data/net.teclo.NeTrace/app_bins/tcpdump

And handily I could also verify the resulting captures, and they showed the 
same data as the control capture.

What version of the product are you using? On what operating system?

This was on CyanogenMod, Android 4.2.2, roottools 3.0 and 3.1.

Cheers!

Original issue reported on code.google.com by cjst...@gmail.com on 30 Jul 2013 at 2:49

[GoogleCodeExporter]

How are you setting the timeout?

Original comment by Stericso...@gmail.com on 31 Jul 2013 at 3:11

[GoogleCodeExporter]

Ahh :) Sorry, my bad. I thought the timeout argument towards the shell was for 
commands. I see now that Commands have their own timeout.

That leaves us with:
a) after the timeout exception was called, the tcpdump process wasn't actually 
terminated.
b) perhaps related: when calling closeCustomShell(), the shell isn't actually 
closed when tcpdump/a process isn't running.
c) is there a way to do the equivalent of sending a sigint to the process? Had 
the vague hope of sending a "\003" command, but that didn't work.

Right now the only way for me to close my running process is to call 
killProcess, which isn't too elegant.

Original comment by cjst...@gmail.com on 31 Jul 2013 at 3:59

[GoogleCodeExporter]

So,

I need to see how I can force the process to kill when a timeout exception 
occurs.

Also, how are you determining that the custom shell is not closing when the 
process is not running, Are you calling the close method on the shell?

I don't think there is a way in Java to send a sigint to the process. However 
there is the process.Destroy() method that should be called when the close 
method is called on the shell.

Original comment by Stericso...@gmail.com on 1 Aug 2013 at 3:16

[GoogleCodeExporter]

Yea, I tried calling either the .close() method on the shell or the 
closeCustomShell() function.

I don't know if the shell isn't closing when the process isn't running. I only 
know the shell isn't closing when the process IS running. Don't know if you 
meant the latter.

If you did mean the latter, I can see from the command-line that the Unix 
process is still alive. See the shell output on TCPdump from above.

Original comment by cjst...@gmail.com on 1 Aug 2013 at 3:33

[GoogleCodeExporter]

Got you, you said:

"b) perhaps related: when calling closeCustomShell(), the shell isn't actually 
closed when tcpdump/a process isn't running.'

Guess that should have been the process "is" running. Anyways, that is a result 
of the fact that the process is still running. So solving the problem of the 
process continuing to run would solve the issue of the shell staying open.

Let me look into this....

Original comment by Stericso...@gmail.com on 1 Aug 2013 at 3:39

[GoogleCodeExporter]

Ah, sorry for the confusion.

Original comment by cjst...@gmail.com on 1 Aug 2013 at 3:50