Bug 131843 – [XvfbDriver] XvfbDriver should avoid trying to use display numbers with stale sockets or locks owned by other user

• Component: Tools / Tests
• Status: NEW

[Carlos Alberto Lopez Perez]

xvfbdriver.py:_next_free_display() looks at the current active process to guess which X displays are already on use on the system. This is correct.

However, when Xvfb (or X) starts it creates both a socket on /tmp/.X11-unix/X$ndisplay and a lock on /tmp/.X$ndisplay-lock. When it shutdowns cleanly it removes both the lock and the socket files, but when is killed (for example on the bots via kill-old-process) the files remains there.

xvfbdriver.py:_next_free_display() don't has this into account, and on the next run it will try to reuse that display number. That isn't a problem if is the same user than before, because Xvfb will clean this stale files. The problem is when is another user trying to run the tests, he don't has permissions to delete the stale lock or socket files owned by the previous user, so Xvfb refuses to start:

Error for /tmp/.X55-lock owned by other user:
(EE) 
Fatal server error:
(EE) Could not create server lock file: /tmp/.X55-lock
(EE) 

Error for /tmp/.X11-unix/X55 owned by other user:
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
(EE) 
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE) 


So this can cause a massive test failure when you have two or more uses running tests (or playing with X) on the same machine (it don't has to be simultaneous).

[Carlos Alberto Lopez Perez]

Related bugs:

https://bugs.webkit.org/show_bug.cgi?id=88414
https://bugs.webkit.org/show_bug.cgi?id=103806

[Carlos Alberto Lopez Perez]

Created attachment 229655 [details]
Patch

[Michael Catanzaro]

Comment on attachment 229655 [details]
Patch

Thanks for this patch. This function was removed in r192568, so this patch will need rewritten for sure. But also since r192568, we no longer check for lockfiles at all, so I'm not sure that this bug is still relevant.