Ideas concerning buildbot (hanging hg processes)

Simon Heimberg Simohe at besonet.ch
Tue Jan 21 18:18:00 CST 2014


Am 21.01.2014 12:44, schrieb Simon Heimberg:
> Could somebody check if there are many hg processes hanging around on
> the windows slave? My guess is that hg serve processes from previous
> test runs are blocking the ports, preventing the test in the next run to
> succeed (details in an earlier mail [1]). But I can not test this theory
> because I can not look into the build slave.

On windows when running "hg serve -d --pid-file=xxx", the pid file 
contains the pid of the spawned shell (of cmd.exe, which starts the hg 
server). When I try to kill the server by this pid (by running "taskkill 
/PID pid_from_xxx" /F), this only terminates cmd.exe, but not hg.exe. 
(At least on my computer running windows7. I can still browse 
http://localhost:8000. On buildbot slave, killing seems to work 
sometimes. "hg serve -d" is in more tests than the failing ones.)

Running buildbot successfully:
We could use the following command as a first or last build step on 
windows slave:
   taskkill /IM hg.exe /F
This would (forcibly) kill all hg tasks, also the ones hanging around. 
(Of course no other hg task should be running.)

Ideas for later:
  * killdaemons.py could use use "taskkill /PID pid_of_cmd /F /T" to 
kill cmd.exe and its children (the hg.exe)
  * We could teach mercurial.win32.spawndetached to return the PID of 
hg.exe by using some win32 function (see [a]). cmd.exe will exit 
automatically when hg.exe is killed, because its child is finished.
  * find a better spawndetached method which does not run cmd.exe


(Command to detect running hg instances:
   tasklist /FI "imagename eq hg.exe")


[a] (see 
http://stackoverflow.com/questions/1173342/terminate-a-process-tree-c-for-windows)

>
<snip>
 >
 > [1] 
http://www.selenic.com/pipermail/mercurial-devel/2014-January/055679.html


More information about the Mercurial-devel mailing list