kdm "not" autostarting

[gurke]

i recently upgraded xorg, to 6.8.0 and kde to 3.3.0. now, when i start my pc the bootup sequence starts as normal and tells me "starting kdm ... [ok]". but kdm is not running. no xserver is running.
when i try to start the xdm service manually, it says its running. then i tried to stop it, but it said: "cannot stop service". so i zap the state and start it again and it works.

does anyone have similar problems, or does anyone know how to solve this?

[gurke]

resyncing, reemerging solved it.

[Valheru]

What did you re-emerge? I have this problem too, except not all the time...

[saleck]

Same problem here (as Valheru) - what have you re-emerged?

[ktech]

same happens here. I think the problem is that kde binaries are no more in the path to binary files.

Executing [path to kde]/bin/kdm as root should be enought in the meantime.

Where are that path directories noted? I don't remember updating base-layout. Perhaps they are on another place?

Thanks!

[saleck]

You are right - I have changed a line in the /etc/init.d/xdm so there is the whole path to the kdm and everything works now - I admit it's an awfull hack but I had no time to play with it more (actualy the $(which kdm) should work... )

[Strunzdesign]

Hi, I have same problem here like "gurke" described.
But my errors were not gone after reemerging kdebase and xorg-x11.

@saleck:
I added some "echo"-statements to my /etc/init.d/xdm. $EXE
is set properly to /usr/kde/3.3/bin/kdm! _This_ does not cause
the error here.

I traced it to the line "/sbin/telinit a &>/dev/null" in
/etc/init.d/xdm, which invokes "/etc/X11/startDM.sh" via inittab.
Added some echo's, and tadaa, this file gets started at boot.
But still no kdm

Ok, I looked at startDM.sh.
The line "/sbin/start-stop-daemon --start --quiet --exec ${EXE}"
gets executed with $EXE set properly to "/usr/kde/3.3/bin/kdm".
It returns with $?==0 (resulting in [ok]), but still no kdm.

It's something happening in start-stop-deamon. Removed the
--quiet, but no error message appears. No kdm in "ps aux | grep kdm".


Now the interesting part:

It seems to me that _sometimes_ kdm was executed at boot, sometimes not.
But that was not correct: KDM is _never_ started by default, only
when you enter a login-name within 2 seconds after appearing of
the login prompt (!!). Test it! Right after pressing enter (username typed),
kdm starts. When you wait longer than 2 seconds, kdm will not start
automatically.

In startDM.sh, there are the following two lines:
# Fix bug #26125 for slower systems
wait; sleep 2

I changed 2 to 30, and were able to stretch the "timeout" to 30 secs.

Try this:
Reboot.
KDM should be started, result is an [ok], but no kdm.
The login prompt appears.
No KDM.
Wait 10 secs (Any value < sleep-value works)
Type "root"
Type <enter>.
KDM will start before you see the password-prompt.

Now you have a working kdm, and CTRL-ALT-F1 does still ask for a password.

What's the link between an executed but not really working
"/sbin/start-stop-daemon --start --quiet --exec /usr/kde/3.3/bin/kde"
and an entered username at /sbin/agetty(??)?

Sounds to me like a problem with some permissions...?!?

Just my $0.02

Florian

P.S. System is 2 weeks old, "x86", xorg-x11 (selective ~x86 by /etc/portage/package.keywords)

[Raistlin]

the same issue here...
i haven't tested it so thoroughly as Strunzdesign - but a strange thing i've seen on my system: kdm seems to get started but killed later (the remaining kdm.pid file under /var/run indicates a unexpected abort, no? )

cheers, raist.
_________________
Zwei Was Eins Initially

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

[ktech]

I think the problem is with the path. A few weeks ago I could do this:

evanescence # kdm

and kdm just appeared.

But now kde apps are just not in the path, so now I have to do:

evanescence # /usr/kde/cvs/bin/kdm

And I'm using kde-cvs so the problem is not kde, but some init script or something like that.

Any clue?

[Raistlin]

i cant confirm that...

executing

[Strunzdesign]

Hi,

from my "/var/log/everything/current" (using metalog):

I logged in terminal, KDM started:
...
Sep 22 17:49:11 [xfs] ignoring font path element /usr/share/fonts/ttf/western (unreadable)_
Sep 22 17:49:11 [init] Activating demand-procedures for 'A'
Sep 22 17:49:31 [kdm_greet] Can't open default user face


Timeout (used 60 secs in startDM.sh), KDM did not start:
...
Sep 22 17:50:57 [xfs] ignoring font path element /usr/share/fonts/ttf/western (unreadable)_
Sep 22 17:50:57 [init] Activating demand-procedures for 'A'
Sep 22 17:51:53 [kdm] X server startup timeout, terminating
Sep 22 17:51:53 [kdm] X server for display :0 can't be started, session disabled
Sep 22 17:51:55 [login(pam_unix)] session opened for user root by (uid=0)

Hope it helps...

Greetings, Florian

[ktech]

we must investigate in order to know what package left out of the path to kde apps.

Who stablishes the path to a gentoo system? baselayout or who?

Cheers

[saleck]

@Strunzdesign:
I had exactly the same symtomps and as I have already written - the script with $(which kdm) should have worked. However with the change I have made everything works - it's really strange...

[Varuna]

Same problem here... KDM doesn't autostart unless I immediately type a username at the console prompt. Typing KDM as root always opens it later. It's happened on two different installs. I'm using XOrg 6.8, KDE 3.3, and GCC 3.4.2 on a completely ~x86 system which is otherwise pretty stable, even with Reiser4. I am using udev, which has sometimes had permissions issues on my older install.

[Strunzdesign]

@saleck:
Your solution does not work here. Sorry, I mean that it works
_sometimes_! :-/
It's curious, the content of $EXE is absolutely the same whether
you set it manually or use `which`. When using which, kdm
does _never_ start automatically here. When using your
workaround, kdm starts with a probability of ~50%.
I'm not able to influence this. I start the computer, and
have kdm or not. Then I log in via ssh, and type in
"reboot" and "exit". After reboot, I see kdm or not. 50%...

Perhaps its simply the fact that there is this "which" command
which has some other side effects? Perhaps a race condition?

We should file a heisenbug at bugs.gentoo.org
It seems that there are many people who suffer from this
bug, and I have really no idea what is happening here.
Perhaps somebody should look at the internals of
start-stop-deamon (and enable some debugging output)
and kdm.

A quick & _dirty_ workaround:
rc-update del xdm default
echo "/usr/kde/3.3/bin/kdm &" >> /etc/conf.d/local.start

Greetings, Florian

[firephoto]

[ktech]

Thu Sep 23 00:24:23 2004 >>> sys-apps/usbutils-0.11-r4
Thu Sep 23 00:24:55 2004 >>> sys-apps/hotplug-20040920

Only these (and most probably "hotplug" could be related to our problem.

What do you think?

[firephoto]

I just got done with a world update and then rebooted. Local started but nothing was happening so I was logging in as root and as I began to type the password kdm started so I'm not sure if it was just a delay or what. Someone else mentioned this too about typing in your user name within 2 seconds so it's probably this. There's a new hotplug version out btw, but it seems to have not changed anything.

[Strunzdesign]

Hi, new infos available
I tested a lot to get my box working again. Still no real results.

All that did not work:
* Downgrade to xorg-x11-6.7.0-r1
* Recompile of kdelibs/kdebase
* Upgrade to xorg-x11-6.7.0-r2 (emerge -uDv world)
* Another recompile of kdelibs/kdebase
* emerge nvidia-glx ; opengl-update nvidia

Then I started to play with the "telinit" command.
Default runlevel is "3" or "a" (invoked by /etc/init.d/xdm start").
I used "telinit 2" and "telinit 3" to switch between a non-kdm
runlevel and a runlevel that _should_ start kdm.

Dry run, works _always_:
/sbin/start-stop-daemon --start --exec /usr/kde/3.3/bin/kdm
KDM appears.
To stop it afterwards, type:
/sbin/start-stop-daemon --stop --exec /usr/kde/3.3/bin/kdm
... tried it 10 times in a row, no single failure.

Another test, "one level higher":
/etc/init.d/xdm start
/etc/init.d/xdm stop
.. works always, no problems.

Ok, now it becomes interesting
telinit 2
..["stopping xyz"]..
telinit 3
..["starting xyz"]
... no kdm appears.

Now, stroke a key on your keyboard and hold it down.
After 5-10 characters kdm will start. Or try single characters.
Type them slowly. No kdm will appear. Type them in faster
(here: >1 cps) and kdm will appear. Curious!

Now it looks like a kernel problem or something in this direction.
Perhaps the keyboard handler of X (kdm_config? look below)?


Next observation:
You need two ttys. Use Alt-F1 and Alt-F2. Log in in both.
On Alt-F2, start "top".
On Alt-F1:
Make sure you have runlevel 2, no kdm
If shutdown of kdm failed, type in
"/etc/init.d/xdm zap".
Try to start kdm: "telinit 3". It should not start.
Switch "carefully" to "Alt-F2" (remember what I told about keystrokes)

Top says:
Immediately: 2 x kdm
After 1-2 seconds:
1 x kdm
1 x kdm_config

This won't change. After 60 secs, still "kdm" and "kdm_config"
there. Switch back to Alt-F1.
Stop it: Type "telinit 2". Maybe kdm won't shut down
properly, then zap'it manually!

Now, second try.
"telinit 3", and animate kdm to start. Press "space" or some other
key, until X starts. Switch immediately to Alt-F2, and watch top:

Immediately:
2 x kdm
After 1-2 seconds:
2 x kdm
1 x kdm_greet

No "kdm_config" visible. Then it starts "kdm_greet". Ok.
There is something happening inside kdm!
**It's a kdm problem**

Remarks:
If "telinit 2" results in "xdm: [!!]", you _must_ zap xdm!
It "telinit 3" does not start kdm, there is an internal timeout
that kills xdm/kdm or something related to this service.
If you press the keys within this timespan, you end up
havinga working kdm.

Else, top does still show "kdm" and "kdm_config".
Remember the "keystrokes-effect". It's still there!
Hold "space", and watch X start. It starts up, but exits
immediately. Xdm is messed up, and has to be zapped.

A lot of stuff... hope it helps.
This bug is a _really_ annoying.

Florian

[Strunzdesign]

@ktech:
The system is "x86":
sys-apps/hotplug-20040401
sys-apps/usbutils-0.11-r3

It is 2-3 weeks old. Genlop says that there
was never an update of hotplug or usbutils.

Greetings, Florian

[ktech]

[Strunzdesign]

Hi,

[Strunzdesign]

Ok, now I'm pretty sure that the problem is in kdm (kdm_config)
or X:

Make sure that kdm will not start automatically:
"rc-update del xdm default"
"reboot"

You need a second box. Ssh to the first box (as root)
and try to start kdm out of the ssh session.

Look at the 1st box' screen. Does ssh start? Yes? Sh*t
Wait 5 seconds, and "killall kdm". Wait 5 seconds again
and restart kdm. This is a pretty random number generator
You do now know after how many steps kdm will fail

When it fails, you end up having "kdm_config" in "ps aux".
Voila.

What's the purpose of kdm_config? Does it start X? Does it
wait for some event (->X)? When we know _why_ "kdm_config"
hangs we have the solution why kdm fails.

Florian

[Strunzdesign]

Ok,

my last idea was to attach "gdb" to the hanging kdm_config.
I got a useless backtrace because kdebase and kdelibs were
compiles without debugging symbols.
I recompiles both (using "debug" in /etc/portage/packages.use)
and ... tadaa.. the bug is no longer reproducable! :-/

A timing problem / hang in kdm_config?

Florian

[firephoto]

Besides the packages I listed above, the only other change was setting up and NFS mount for portage to share the tree on this box so the other just mounts this share. Could this have changed the startup timing somehow?