view tests/test-xdg.t @ 37212:f09a2eab11cf

server: add an error feedback mechanism for when the daemon fails to launch There's a recurring problem on Windows where `hg serve -d` will randomly fail to spawn a detached process. The reason for the failure is completely hidden, and it takes hours to get a single failure on my laptop. All this does is redirect stdout/stderr of the child to a file until the lock file is freed, and then the parent dumps it out if it fails to spawn. I chose to put the output into the lock file because that is always cleaned up. There's no way to report errors after that anyway. On Windows, killdaemons.py is roughly `kill -9`, so this ensures that junk won't pile up. This may end up being a case of EADDRINUSE. At least that's what I saw spit out a few times (among other odd errors and missing output on Windows). But I also managed to get the same thing on Fedora 26 by running test-hgwebdir.t with --loop -j10 for several hours. Running `netstat` immediately after killing that run printed a wall of sockets in the TIME_WAIT state, which were gone a couple seconds later. I couldn't match up ports that failed, because --loop doesn't print out the message about the port that was used. So maybe the fix is to rotate the use of HGPORT[12] in the tests. But, let's collect some more data first.
author Matt Harbison <matt_harbison@yahoo.com>
date Wed, 28 Mar 2018 00:11:09 -0400
parents 7d8da7b54dc0
children a4b3b8dee0a8
line wrap: on
line source

#if no-windows no-osx

  $ mkdir -p xdgconf/hg
  $ echo '[ui]' > xdgconf/hg/hgrc
  $ echo 'username = foobar' >> xdgconf/hg/hgrc
  $ XDG_CONFIG_HOME="`pwd`/xdgconf" ; export XDG_CONFIG_HOME
  $ unset HGRCPATH
  $ hg config ui.username 2>/dev/null
  foobar

#endif