Closed Bug 493449 Opened 15 years ago Closed 14 years ago

windows slaves act strange, e.g. reftest and mochitest-plain failures

Categories

(SeaMonkey :: Release Engineering, defect)

x86
Windows Server 2003
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kairo, Assigned: kairo)

References

Details

(Whiteboard: [Fixed by bug 571855])

cb-seamonkey-win32-02 has some not yet clearly defined problem, it auto-starts buildbot in a way that I can't see the processes running as seabld even when I log in as seabld, and auto-starts once again when I log is a seabld I get another buildbot running. I suspect that the systematic reftest and mochitest-plain failures we're seeing are connected to this.

The strange thing is that -win32-01 should be set up identically but is working correctly.
I now killed all seabld processes from an Administrator login and then logged in as seabld, which autostarted buildbot again. Let's see if that makes a difference.
Assignee: nobody → kairo
Status: NEW → ASSIGNED
OK, unittests seem to run OK from the buildslave started with the regular login. I still need to find out what causes the autologin to end up botched in a way that it creates those errors. For now, the machine should work fine until it gets rebooted (which could happen tomorrow when the Parallels issue is being debugged).
This happens consistently on both VMs now when they start the autologin after a reboot. logon.src (the login screen saver!) is running in parallel to the python process, it somehow looks like seabld would never fully log on but already start buildbot from the Startup menu.
Again, when I log in as Administrator, kill those processes, and log in as seabld (all from RDP), everything works fine.

Ben, have you guys seen things like that on Windows VMs?
Severity: normal → major
Whiteboard: [see comment 3]
NOT major because it's no production setup yet and we have a well-working workaround for now.
(In reply to comment #4)
> NOT major because it's no production setup yet and we have a well-working
> workaround for now.

Well, I'd say _major_ precisely because it prevents from switching this (newer) setup to production :-|
(Though I agree our current (older) production setup is still running (fine enough).)
cb-seamonkey-win32-02 misbehaves currently: can you fix it?
(In reply to comment #6)
> cb-seamonkey-win32-02 misbehaves currently: can you fix it?

Done, should be OK again. I still need to find out what we are doing differently than on Firefox machines that could cause this, but for the moment, we look fine again.
Summary: cb-seamonkey-win32-02 acts strange, e.g. reftest and mochitest-plain failures → windows slaves act strange, e.g. reftest and mochitest-plain failures
Component: Project Organization → Release Engineering
QA Contact: organization → release
Fixed by bug 571855.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Depends on: 571855
Flags: in-testsuite-
Whiteboard: [see comment 3] → [Fixed by bug 571855]
You need to log in before you can comment on or make changes to this bug.