[Webkit-unassigned] [Bug 131843] New: [XvfbDriver] XvfbDriver should avoid trying to use display numbers with stale sockets or locks owned by other user

[bugzilla-daemon at webkit.org]

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

           Summary: [XvfbDriver] XvfbDriver should avoid trying to use
                    display numbers with stale sockets or locks owned by
                    other user
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: clopez at igalia.com


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).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.