Ideas concerning buildbot (hanging hg processes)
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 ). 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
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")
More information about the Mercurial-devel