After logging in via qingy and at the start of an X session, X will hang trying to load a session of /etc/X11/Sessions/Gnome. (I'm thinking all other sessions will display a similar hang after trying to start a session of Enlightenment & Gnome). sys-apps/qingy-0.6.0 x11-base/xorg-x11-6.8.2-r1 Reproducible: Always Steps to Reproduce: 1. Login or press enter after entering password via Qingy 2. X starts with the black and white matte with an X cursor and hangs. 3. ps -axf shows the particular /etc/X11/Sessions/* hanging with the -nolisten and other options. (Haven't had time to debug further.) Actual Results: Hang on start of X Expected Results: Login and start a specified session of Enlightenment, Gnome, ... na
1. Does qingy work on text sessions? 2. Would you please try starting a more minimal window manager with qingy? WindowMaker or fluxbox are best for this test... If they do work, your issue lies elsewhere, and is not related to qingy. I experienced your exact problem when I switched to kernel 2.6.12, and it was a firewall problem. Gnome wouldn't start, hanging as soon as its splash screen appeared, waiting forever for a connection that the firewall was blocking, even if I had a rule that let it pass (and worked in kernel versions up to 2.6.11). Same for kde. Solved it by changing the rule and making it slightly less restrictive...
Yes. Qingy works on text login sessions. No other windowmanager works (ie. fluxbox, my .xsession, gnome, kde, ...) Yes, I understand that it might be a firewall issue hanging X to continue. I have seen this in the past (ie. "nolisten" option). However, I do not have a problem with gdm logging me into X at all. I've seen this issue with both 2.6.11 & 2.6.12. (I've been currently trying to make sure by ip security modules from the kernel before trying to use qingy. I have just booted without the modules loaded, so will try try again, however, I ahve already tried with unloading the majority of them. -- These mdoules are required for shorewall & yes, shorewall is stopped.) [Guess Work: I'm really wondering if this has to do with the qingy c code trying to execute a shell script and causing a hang at this point -- ie. sometimes when I put a exec line in my .xsession without the '&' sign, the .xsession file will hang at the exec line without the '&'. Dunno.. guessing again.]
> [Guess Work: I'm really wondering if this has to do with the qingy c code > trying to execute a shell script and causing a hang at this point -- ie. > sometimes when I put a exec line in my .xsession without the '&' sign, the > .xsession file will hang at the exec line without the '&'. Dunno.. guessing > again.] That's because if you don't pass the & the app will be executed in the foreground (of the script), thus blocking further script parsing until said app terminates. In fact, X init scripts are supposed to start everything in the background, except for the last entry (otherwise X would instantly shut down, because the init script terminates), which is generally the window/session manager, so that when you quit it, X exits. This has nothing to do with qingy, tough, as it executes existing (gentoo-provided) session scripts, which are correctly shaped. >Yes, I understand that it might be a firewall issue hanging X to continue. I >have seen this in the past (ie. "nolisten" option). Keep in mind that qingy, by default, does pass the '-nolisten tcp' arg to the X server. If you don't want it, please comment out the x_args variable in /etc/qingy/settings.
I understand foreground/background. This is how X is behaving. It's hanging waiting for something to happen. Whether it's a task that should be running in the background, I don't know.
Sorry for being slow in responding... I have been busy in the Real World lately. Plus I'm leaving for some (needed) holidays. Will be back on Autust, the 16th...
Does it work if you boot without any of these firewall modules loaded?
Since I got no other feeback of this kind, plus I cannot reproduce the issue (I had a similar one once on my machine, and it was a firewall problem), I assume this is a problem on your specific setup, and qingy only triggers it.
