You are not logged in.
* My original problem
I wrote my own script that will send out a multicast, which can be received by my other PC. I configured Xfce on this test PC to run this script when I log in. I also configured slim to automatically log me in. That means that whenever this PC boots up and autologs in, my other PC will show a notification on the desktop that the test PC has logged in.
But when I unplugged the VGA cable from the test PC and booted it up, my other PC did NOT detect any multicast notifications. Some troubleshooting shows that when the test PC boots up without a monitor, the process "/usr/bin/slim -d" is NOT running, when it normally should be running.
I did a quick test with Daedalus + Xfce + slim with no monitor connected, and "/usr/bin/slim -d" IS running, which is the expected result. So I am suspecting that something has changed between Daedalus slim's code and Excalibur slim's code, and this change caused Excalibur slim to crash when there are no monitors detected.
Can anyone try to reproduce the problem following the steps below? Has anyone seen or heard of this problem before?
I'll spend some time compiling and debugging slim again so I can find the root cause, but if there's already a solution, that will save me some time and energy.
* Steps to reproduce
- If you have slim auto login turned on, turn it off. Edit /etc/slim.conf, comment out "auto_login". This shows that slim's auto login is NOT the cause of the problem.
- Using a stopwatch, reboot the PC. Time how long it takes for the PC to go from the BIOS to the login screen. We'll need that when we do this without a monitor.
- CTRL+ALT+F1 to go to the tty1 terminal. Log in.
- ps -ef | grep slim. This should show 3 lines:
/usr/bin/slim -d
/usr/lib/xorg/Xorg <various args>
grep slim- Turn off the PC.
- Unplug all video cables from the PC. Turning off the monitor might not be enough, because the PC can still detect the monitor.
- Turn on the PC.
- Wait for the duration measured by the stopwatch.
- Plug in the video cable.
- Press CTRL+ALT+F1 to switch to the tty1 terminal.
- If you don't see the tty1 terminal, you may have to fiddle around. Try the other terminals CTRL+ALT+F2 through F6. Try turning off/on the monitor.
- Alternatively, if you have a 2nd PC, you can telnet/ssh into your test PC to run these commands.
- ps -ef | grep slim. Instead of showing 3 lines, only TWO are shown:
/usr/lib/xorg/Xorg <various args>
grep slimOffline
it is normal. i dont know its internals but i quess slim is not designed to work without a monitor connected.
When you connect a monitor later it is already too late that slim give up and quit.
Because there is no event listener/handler that catcth that PLUG event then do appropriate i quess.
you have to write that listener/handler yourself and order it to fire slim when event catched.
Or you have to wait until monitor is plugged
or make some service fire up slim every 1 second until its succeeded
or get rid of slim and autologin by some other means.
Take all this as a grain of salt.
Last edited by wert (Yesterday 04:44:11)
Offline
@wert - I don't think what I'm seeing is normal. I just tested my Daedalus + Xfce + slim PC, and I set the same auto login + the same running of my multicast script on login. Then I turned off the PC, unplugged the VGA monitor cable, and turned it back on. My PC with the multicast listener DID receive the multicast, indicating that slim USED to work without needing a monitor.
I finished compiling and debugging the Excalibur slim's source code, and I'm about to write a technical explanation. For a quick explanation, there's new code in this slim that creates a temporary window that fits on one monitor. To do so, it tries to find the dimensions of the primary monitor. But the author never handled the case of having NO monitor connected. So the code thinks that the primary monitor's width/height is 0/0. Amazingly, the window IS successfully created, at least, programmatically, but the code later crashes on another X function, specifically, XGetWindowAttributes(). My guess is that XGetWindowAttributes() might be dividing by 0 somewhere in its code.
Offline
* Analysis
Having debugged slim before for a different problem, I was able to hunt down the crash and explain the problem quickly this evening. But I don't have a solution, since I don't fully understand what this code was intending to do.
The crash occurs in panel.cpp, Panel::GetColor(), on this line:
XGetWindowAttributes(Dpy, Root, &attributes);But the problem is caused by Panel::GetPrimaryViewport(). In this function, there's new code (compared to Daedalus slim) that was added to create a child window that's the width/height of just the primary monitor. My best guess is that this was supposed to solve a problem for users with multiple monitors, where slim's login GUI might get stretched onto a 2nd monitor, or something like that.
The problem is that the code logic for finding the primary monitor's width/height never handled the case where there's NO monitor connected. In this case, the code gets back that the width/height is 0/0. The code then proceeds to create this child window using XCreateSimpleWindow(), and I think this function actually succeeds, at least, programmatically, despite being given a width/height of 0/0.
My semi-wild guess for why XGetWindowAttributes() crashes is that it's running into a divide by 0 on the width or height. I've confirmed that if either the width OR the height is 0, XGetWindowAttributes() crashes.
* Devuan's existing patch for slim
Devuan already has a patch to fix a slim auto login problem where the blank window is shown. Here's a condensed version:
/* // Disable, see Devuan#857
Root = XCreateSimpleWindow ();
XMapWindow();
XFlush();
*/The patch eliminates this child window, so slim uses the root X window, just as it did in Daedalus slim.
I tested this patch, and confirmed that this patch ALSO fixes this crash without a monitor. I think that's because the root window is created with a default resolution of the once popular 1024x768, so the rest of the X code works correctly without crashing.
So the conclusion so far is that this multimonitor feature added to slim needs more work, as it has now caused two problems - untitled window, and monitorless crash.
So the next question is, what should I do? Should I file a bug with Debian slim, since this is a separate issue?
Offline
IMO it is appropriate that:
* Slim must check whether or/not there is a monitor or multiple monitors to put something.
Not blindly do something itself.
* if there is NO monitor at all then it simply go to idle and wait for one to plugged.
listen for plug or check periodically.But that up to user to decide; So it exposed config option to user to what to do when NO monitor, just quit or go to idle and wait?
if slim wants to support headless and/or network login and/or forward the login window on network then it must provides related config options to its users to decide. it is up to user to decide not slim.
if slim wants to work with multiple monitor case then it is exposed related config options to users to decide. then user decides eg:
*present yourself on both monitor simultaneously to interact/login.
*use ID=xyfoobar monitor
*use internal monitor ignore others
* ... likewise
So feel free to file a bug.
Offline
A related situation is when you have more than 1 system sharing a monitor via a KVM switch. In my experience if you boot a system when the KVM switch is connecting the monitor to another system the system you are booting can't see the monitor's resolution etc. This is another case you might want to cater for (hopefully it will be covered by your patch anyway).
Offline