[ubuntu-x] Ibex x server a little TOO hot-pluggy?

[Bryce Harrington]

On Mon, Nov 03, 2008 at 06:07:21AM -0800, Dan Kegel wrote:
> I'm running the wine tests on an automated test cluster,
> and I had been perfectly happy using just one monitor
> on all machines, moving the cable to the machine
> I wanted to look at.
>
> With Ibex, however, that seems to have broken.  Several
> times I've moved the cable to discover that a
> machine which had been running fine the night
> before now is in reduced resolution mode, and
> a nasty "reduced resolution, want to troubleshoot?" (not verbatim)
> dialog is up instead of the test user's desktop.
>
> I think this happens after just a few hours of no monitor.
> This kind of prevents any useful work from getting done.
> 
> Is this by design?   Is the x.org server in ibex supposed
> to throw a fit if the monitor is unplugged for hours?

I've got a similar setup using an 8-port KVM.  I've not seen this
failure scenario before, however I suspect your use case and mine are a
bit different.  But from your description I can guess what's going on.

It sounds like your system is crashing for whatever reason while the
monitor is unconnected.  It is then attempting to restart X, but then is
getting stuck because no monitor is available.  Not knowing how to
configure things, it exits with an error.

The dialog is part of the bulletproof-x system, which is just a failsafe
system that kicks in if your system wasn't able to start X.  It's got a
few basic troubleshooting/configuration options in its menus.  The logs
you collected already tell the story, however:

 (II) intel(0): Output VGA disconnected
 (WW) intel(0): No outputs definitely connected, trying again...
 (II) intel(0): Output VGA disconnected
 (WW) intel(0): Unable to find initial modes
 (EE) intel(0): No valid modes.
 (II) UnloadModule: "intel"

It wasn't able to find a monitor and therefore exits with an error.

> I suspect that to diagnose this I need to grab logs *before*
> clicking "start a new X" on the error dialog.
> The test script shows that testing seems to have stopped
> at 21:28 on 11-02, the same as Xorg.0.log.old's timestamp,
> and shortly before the timestamp of the unexpected Xorg.failsafe.log.old.
> Xorg.0.log above is after I came in and clicked "OK" on the
> "should I restart X" (not verbatim) dialog.

Right, so at 21:28 you seem to have had a system crash.  It could have
been an xserver crash for some reason, or even could be a kernel
crash/restart (which `uptime` would obviously prove/disprove).

In any case, if you'd had a monitor connected, the system would restart,
detect the monitor, configure itself, and leave you at the gdm (or kdm)
login screen.  But since you have no monitor, it's gotten confused and
failed to auto-configure.

Now, I've booted systems with no monitor connected, and it *should*
work, so I think you should file a bug on it.

> If so, is there a way to inhibit this unwanted hot-plugginess,
> and freeze x's configuration?

You can still hardcode xorg.conf to override the automatic detection
stuff.  See `man xorg.conf` for details.  The failsafe dialog you ran
into also has a couple menu items for generating static xorg.conf
configurations you could experiment with.

Bryce