Add a new script forked_adb_logcat_monitor.py.

Add a new script forked_adb_logcat_monitor.py.

The new script is based on the existing script
adb_logcat_monitor.py. The difference is that the new script
spawns the logcat watchers in a different forked process.

Revision 6f2240ded5a22b6e3f75437966ea632b90362448
(https://chromiumcodereview.appspot.com/24456002/) added something
similar to adb_logcat_monitor.py itself, but it was found to be
insufficient for the recipes framework. Essentially, the recipes
system expects the standard streams to be closed at the end of a
step. To avoid adding more clutter to the existing script, this
CL reverts the previous changes to adb_logcat_monitor.py and adds
a new script to handle the recipe requirements. Also, as
mentioned above, if we put these changes in one script
(adb_logcat_monitor.py), I am hitting problems with the
existing annotator scripts which use adb_logcat_monitor.py.

BUG=286509

[Siva Chandra, 2013-10-03 22:10:58]

I abandoning the other CL as the try jobs, though green, were having logcat
monitor problems. This CL reverts all forking changes to adb_logcat_monitor.py
and adds a new script which can be used from recipes.

Tested locally. Try jobs in queue.

[Siva Chandra, 2013-10-03 23:10:17]

BTW, the new script is based on this:
http://www.jejik.com/articles/2007/02/a_simple_unix_linux_daemon_in_python/

[navabi, 2013-10-03 23:51:04]

https://chromiumcodereview.appspot.com/25679007/diff/1/build/android/forked_a...
File build/android/forked_adb_logcat_monitor.py (right):

https://chromiumcodereview.appspot.com/25679007/diff/1/build/android/forked_a...
build/android/forked_adb_logcat_monitor.py:20: if __name__ == '__main__':
move the body of this into a main function.
if 2 <= len(sys.argv) <= 3:
  sys.exit(main(*sys.argv[...]))

https://chromiumcodereview.appspot.com/25679007/diff/1/build/android/forked_a...
build/android/forked_adb_logcat_monitor.py:38: # do second fork
Why is there a second fork? For the adb_reboot_on_disconnect we only did one
fork. I tried to find the explanation for the second fork from the link, but it
refers to another link that doesn't work:
http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC16

It would be good to have a comment explaining the need for the second fork.

[Isaac (away), 2013-10-04 00:56:03]

On 2013/10/03 22:10:58, Siva Chandra wrote:
> I abandoning the other CL as the try jobs, though green, were having logcat
> monitor problems. This CL reverts all forking changes to adb_logcat_monitor.py
> and adds a new script which can be used from recipes.

Please do the revert in a separate CL so it is not blocked on a review and does
not risk getting rolled back.


> 
> Tested locally. Try jobs in queue.

forked_adb_logcat_monitor.py looks like a general daemon launcher.  I'd prefer
we not name utilities based on how they are used.  Instead, how about writing a
general class, perhaps just using:
http://code.activestate.com/recipes/278731-creating-a-daemon-the-python-way/ ?

[iannucci, 2013-10-04 01:33:31]

On 2013/10/04 00:56:03, Isaac wrote:
> On 2013/10/03 22:10:58, Siva Chandra wrote:
> > I abandoning the other CL as the try jobs, though green, were having logcat
> > monitor problems. This CL reverts all forking changes to
adb_logcat_monitor.py
> > and adds a new script which can be used from recipes.
> 
> Please do the revert in a separate CL so it is not blocked on a review and
does
> not risk getting rolled back.
> 

Probably a good idea :)

> 
> > 
> > Tested locally. Try jobs in queue.
> 
> forked_adb_logcat_monitor.py looks like a general daemon launcher.  I'd prefer
> we not name utilities based on how they are used.  Instead, how about writing
a
> general class, perhaps just using:
> http://code.activestate.com/recipes/278731-creating-a-daemon-the-python-way/ ?

Yeah we should have some sort of daemon class as a library somewhere.