Bug 131843 - [XvfbDriver] XvfbDriver should avoid trying to use display numbers with stale sockets or locks owned by other user
Summary: [XvfbDriver] XvfbDriver should avoid trying to use display numbers with stale...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2014-04-18 07:57 PDT by Carlos Alberto Lopez Perez
Modified: 2016-01-02 09:41 PST (History)
7 users (show)

See Also:

Patch (3.22 KB, patch)
2014-04-18 10:47 PDT, Carlos Alberto Lopez Perez
mcatanzaro: review-
mcatanzaro: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Alberto Lopez Perez 2014-04-18 07:57:58 PDT
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:
Fatal server error:
(EE) Could not create server lock file: /tmp/.X55-lock

Error for /tmp/.X11-unix/X55 owned by other user:
_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
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).
Comment 1 Carlos Alberto Lopez Perez 2014-04-18 08:01:11 PDT
Related bugs:

Comment 2 Carlos Alberto Lopez Perez 2014-04-18 10:47:43 PDT
Created attachment 229655 [details]
Comment 3 Michael Catanzaro 2016-01-02 09:41:02 PST
Comment on attachment 229655 [details]

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.