I have the same problem, with a Gentoo installation of 3.4.0_beta1.

i need the daemon syslog of a "kdm -debug 1" run.

Created attachment 9258 [details]
kdm syslog output

Oh, sorry, forgot to comment. This is the SuSE /var/log/messages. It shows the boot process and a first start of the KDE 3.4beta. Then I used a "init 3" and a "kdm -debug 1". I hope this is the information you need, otherwise please just reply.

Regards,
tM

this log does not indicate any delay during the actual shutdown (once the kdm backend receives the shutdown command). interesting would be the time between pressing enter and the "shutdown command" log message.
btw ... you are shutting down from a running session, not from the login screen, right? what happens if you run "kdmctl shutdown reboot forcenow" from a failsafe session and exit this session afterwards?

Yes, I'm shutting down from a running session (K-menu/log-out). I tried you kdmctl command, but the delay remained.
Ok, I checked the situation and created another Log:

...
Jan 25 12:24:58 AthlonXP1800 kdm[9710]: control socket for :0 received 'caps'
Jan 25 12:24:58 AthlonXP1800 kdm[9710]: select returns 1
Jan 25 12:25:28 AthlonXP1800 last message repeated 2 times
Jan 25 12:25:28 AthlonXP1800 kdm[9710]: control socket for :0 received 'shutdown' 'halt' 'ask'
Jan 25 12:25:28 AthlonXP1800 kdm[9710]: select returns 1
Jan 25 12:25:29 AthlonXP1800 kdm: :0[9716]: ping X server
Jan 25 12:25:29 AthlonXP1800 kdm: :0[9716]: X server alive
...

At 12:24:58, I told kdm to shutdown/reboot. For 30 seconds you can do whatever you want - start programs/open menues ... (this time I didn't do anything)
At 12:25:29 the shutdown is initialized and everything goes down
Seems to be that there are about 30 seconds delay (with no programs running)- without any logged errors. 

and what happens when you shut down from the login dialog?

...then the system is immediately going down (init 6) - I didn't recognize this, because SuSE has this 'enable auto-login' feature per default on.
Also I learned that not only shutdown/reboot has a delay, but also "quit actual session" (about the same time).But the 'switch user' in the kicker menu ('Lock Current Session & Start New Session' - or 'Start New Session') reacts instantly.

Please note that my "me too" comment above doesn't involve kdm, as I don't use it.

From the K-menu, I select logout, and click the button on the confirmation screen.  The system then returns to the desktop where I can continue to use it however I like.  The system stops the KDE desktop about 10 seconds later.

With the new Qt packages (Version 3.3.4) the system again behaves normal and kde is as fast switching down as it should... - kde 3.3.91 is as solid as a rock! 
Sorry for the inconvenience and thanks for your help!

Same problem here; update to 3.3.4 doesn´t change anything. It´s independent of kdm, no log entries. When I start kde via startx, I can´t see any "intresting" log messages on the console while the system delays.

I did compile kde3.4 without arts, might that be the problem?

After all, think this bug should be reopened...

Sebastian

Ok, reopened.
 I thought the new qt 3.3.4 packages solved these matters, but it seemed to be something else...
 Sebastian, can you please report what version of aRts you've installed and whether you use SuSE rpms or something different?
 It's because the SuSE packages prevent some programs like k3b or basKet from compiling (and maybe they are responsibel for even more).
 I've made my own arts rpm (050129 snapshot from the kde ftp) so that these programs could be compiled and I think, I did that the same day I installed the new qt. And I believe that those two thing are the only ones I've changed.
Well, I hope we will smash this bug soon!

I don´t use any version of arts. My distro is Gentoo, and I installed KDE from sources with the "--without-arts"-switch.

I tried to discover some system activity during the delay - but seems there is none. The system response to user activity is fast, no network traffic, no cpu load (99.9% idle). Does anybody know where to start looking in the source?

Sebastian

Created attachment 9425 [details]
Workaround - set knotify timer value to 200ms instead of 20000ms

The problem is related to the logoff-sound. In ksmserver/server.cpp there´s a
timer waiting for knotify playing the sound. As I don´t use aRts knotify
doesn´t play any sound (knotify isn´t working with alsa so far). So ksmserver
waits for the full time (20sec) until it starts killing apps.

For some reason it´s not sufficient to remove any sounds from the event
"logout from KDE" - the timer is still fired. The attatched patch sets a timer
value of only 200ms. That´s ok for my no-arts config but might lead into
trouble when using arts and/or playing logout sounds.

Found that the 20sec-timer was introduced to fix #58721. Maybe the redesign of
knotify to make it work without arts provides a better way to solve this issue
than simply adding a timer?

Sebastian

PS: It´s not neccessary to compile the whole kdebase-package to apply the
patch. After applying the patch just do a ./configure and set "--prefix="
according to your kde installation (SuSE does it in /opt/kde AFAIK, Gentoo uses
/usr/kde/3.4). Change to kdmlib subdirectory and do "make", then go to
ksmserver directory and do "make && make install". This builds only ksmserver
and installs the new binary.

Does anybody know whether the problem still exists in the new 3.3.92 beta?
Can't check it, because the new Suse packages have a working aRts (and a nasty keyboad problem! -check the Internet befor installing!!!)
I'll close this, as soon as I get the confirmation that the patch was applied.

The problem still exists for me with 3.3.92.  There is about a 15 second delay from the time I hit the logout button, to when the screen goes blank, and another 5 seconds or so before I'm returned to the command prompt.

Yes, also on my system. The bug is still present in 3.3.92 - and it always happens when aRts is not working (not really working, I suppose, because players like amarok are just fine, but the notifying system isn't)

Note that my system is configured "--without-arts" (it's not even installed).

I know. The issue occurs, if you have no arts, or an arts, which is not working properly -with the patch of Sebastian all should be fine. So this is something to iron out for the developers.

(To be honest, I really fight with the SuSE arts packages. They also make trouble when I compile programs)

So, I leave this bug open until the issue is really resolved...

CVS commit by lunakl: 

Don't claim knotify could be started when repeated attempts to lauch it fail.
BUG: 97482


  M +6 -3      knotifyclient.cpp   1.60


--- kdelibs/kdecore/knotifyclient.cpp  #1.59:1.60
@@ -226,8 +226,11 @@ bool KNotifyClient::startDaemon()
 {
   static bool firstTry = true;
-  if (firstTry && !kapp->dcopClient()->isApplicationRegistered(daemonName)) {
+  if (!kapp->dcopClient()->isApplicationRegistered(daemonName)) {
+    if( firstTry ) {
     firstTry = false;
     return KApplication::startServiceByDesktopName(daemonName) == 0;
   }
+    return false;
+  }
   return true;
 }

*** Bug 99111 has been marked as a duplicate of this bug. ***

*** Bug 99438 has been marked as a duplicate of this bug. ***

Have such problem on KDE 3.4.2 with arts enabled

Please submit a new bugreport for your problem. This bugreport was about having the problem only when compiling without arts.