Closed Bug 565268 Opened 11 years ago Closed 11 years ago

Need to clean up MozMill vnc connections on Linux if mozmill dies

Categories

(Thunderbird :: Build Config, defect)

All
Linux
defect
Not set
normal

Tracking

(thunderbird3.1 .7-fixed)

RESOLVED FIXED
Thunderbird 3.3a1
Tracking Status
thunderbird3.1 --- .7-fixed

People

(Reporter: standard8, Assigned: jhopkins)

References

Details

(Whiteboard: [test-only change])

Attachments

(1 file)

I'm not sure if this should be a buildbot thing or a MozMill test harness thing.

In any case, from watching staging, we definitely need something to be cleaning up the VNC files if Thunderbird under MozMill dies, as otherwise we just head into the land of permanent failures

For example:

http://tinderbox.mozilla.org/showlog.cgi?log=ThunderbirdTest/1273645665.1273647255.1261.gz#err4
I had added logic that forces us to try and use 'vncserver kill' to kill the previous VNC instance if one is still around when we go to run.  It looks like that is the step that is failing, which is surprising.

Maybe a better question is whether the script should be trying to spin up VNC servers on our tinderboxen at all.  Unless we start recording the runs in a VNC-movie-thing for after-the-fact analysis, I would not expect the tinderboxen would really be benefitting from that extra VNC server getting spun up.  And certainly the hardcoded port is not particularly elegant in the first place... I was originally hoping the tinderboxen were not so configured to use vnc, but it makes sense that they would be...

In any event, we can probably just add an additional exception handler to the case where we fail to kill the server and just remove the xsocket at /tmp/.X11-unix/X$num.

A wrapper script we might be able to mine from (and I take the file path from) is:
http://code.google.com/p/semicomplete/source/browse/xdotool/t/ephemeral-x.sh
(In reply to comment #1)
> I had added logic that forces us to try and use 'vncserver kill' to kill the
> previous VNC instance if one is still around when we go to run.  It looks like
> that is the step that is failing, which is surprising.
> 
> Maybe a better question is whether the script should be trying to spin up VNC
> servers on our tinderboxen at all.

Yes, I agree, it's not needed at all. And unless I am wrong, the mozmill target on comm-1.9.1 doesn't do that, so I guess it's a new feature.

Would be nice to just have some way to enable/disable that feature, and disable it via buildbot.
So I would need asuth to chime in here - do we need this VNC stuff on our tinderboxes?

Does it make mozmill more stable on them? (where we don't care about people interacting?)
The run-mozmill-in-VNC capability was intended as a developer sanity feature so that the tests didn't make the X session useless and to avoid further focus snafus, especially when using window managers configured to not be responsive to demands by windows to be focused.  Neither of those are a concern on the tinderbox.

The current logic checks for the presence of /usr/bin/vncserver and ~/.vnc/passwd.  If they're both there, it uses vncserver to run things under a session created as :99.  The python script obviously has a lot of choices as to how to detect things.  My goal was to avoid needing users to opt-in even more to the vnc mechanism, but I'm not opposed to make the whole thing opt-in by a ~/.thunderbird-mozmill-vnc-enable file or something.  Alternatively, the tinderboxen could opt out.  Thoughts?
(In reply to comment #4)
> [...]
> 
> The current logic checks for the presence of /usr/bin/vncserver and
> ~/.vnc/passwd. 

The problem is that Linux refplatform builders already use VNC themselves for remote access, so both of these will indeed be present.

> My goal was to avoid needing users to opt-in even more
> to the vnc mechanism, but I'm not opposed to make the whole thing opt-in by a
> ~/.thunderbird-mozmill-vnc-enable file or something.  Alternatively, the
> tinderboxen could opt out.  Thoughts?

Yeah, makes sense to keep the default behaviour the best one for developers. Just add a way for buildbot builders to opt-out, ideally, via an environment variable (i.e. MOZMILL_NO_VNC=1)
Assignee: nobody → john.hopkins
Attachment #451366 - Flags: review?(bugzilla)
Comment on attachment 451366 [details] [diff] [review]
Patch to allow override of VNC server usage

Yes, this looks fine. r=Standard8
Attachment #451366 - Flags: review?(bugzilla) → review+
changeset:   5833:386df12e1a80
tag:         tip
user:        Philippe M. Chiasson <gozer@mozillamessaging.com>
date:        Wed Jun 16 16:36:54 2010 -0400
summary:     Bug 565268 - Disable vncserver logic if MOZMILL_NO_VNC is set in the environment. p=jhopkins,r=Standard8,r=gozer
Now that we have a way to disable this stuff when run via buildbot, I don't really care about this particular bug anymore.

I still think the vnc startup logic needs fixing, if only for developers who use this mechanism. Re-assigning to asuth.
Assignee: john.hopkins → nobody
Component: Release Engineering → Build Config
Product: Mozilla Messaging → Thunderbird
QA Contact: release → build-config
Version: other → Trunk
Comment on attachment 451366 [details] [diff] [review]
Patch to allow override of VNC server usage

a=Standard8 as I want to take onto comm-1.9.2 to support running MozMill tests on try server there.
Attachment #451366 - Flags: approval-thunderbird3.1.6+
Checked into 1.9.2: http://hg.mozilla.org/releases/comm-1.9.2/rev/a6f496b08ec9

Tinderbox still passes.


If asuth wants to clean up the VNC startup logic, then we should deal with that in a separate bug, so please file one if appropriate.
Assignee: nobody → john.hopkins
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [test-only change]
Target Milestone: --- → Thunderbird 3.3a1
You need to log in before you can comment on or make changes to this bug.