Hello KDE forum,

I am running KDE 4.11.5:4 on Gentoo but when I right click on a vacant part of the desktop and click on "leave" from the drop down menu, nothing happens, no dialogue box appears to offer shutdown options. A dialogue box DOES appear if I attempt to logout or restart from the Start menu. However, if I logout then log back in (from the Start menu), the problem goes away, and it stays fixed for any subsequent logouts and logins. In other words, the problem only occurs from a fresh reboot. I have tried disabling system sounds but it did not help. My desktop is in folder view and in system settings I have "restore previous session" checked and if I check "start from empty session", the problem still remains.

I was wondering if anyone might offer me some suggestions as to how to fix this?

Thanks much,
Roy

Hm, rather unusual problem. Does the Leave/Shutdown applet encounter similar issues? Also, can you verify that KRunner is running and fully operational?
Finally, does your system use autologin, and if so, does disabling that and logging in manually affect the issue?

Hello bcooksley,

I did not quite know what you meant about the shutdown/loggin applet but I did install a lock-screeen / loggout widget which was installed on the desktop, but it did not bring up the shutdown/loggout dialogue box but it did successfully lock the screen.

Krunner is up and running without apparient error according to the system processes utility (system monitor).

It also made no difference if I used auto-login or a password prompt when logging in.

I re-installed krunner and it fixed the problem on the first try but after that, the problem continued as usual.

I also logged in as a different user (test user) but the problem remained there also.

I have "restore previous session" checked in System Settings but sometimes some of the applications that were open on the last reboot do not appear. I have to manually launch them again. Perhaps this behaviour is a clue.

Thanks for your input.

Roy

Can you please enable all debug output (using kdebugdialog) then tail ~/.xsession-errors while trying to shutdown/logout by right clicking on the desktop?

Hello bcooksley,

$ tail /home/royroy/.xsession-errors
"/org/freedesktop/UDisks2/drives/SanDisk_ImageMate_II_000000000008" : property "Device" does not exist
X Error: BadWindow (invalid Window parameter) 3
Major opcode: 20 (X_GetProperty)
Resource id: 0xc0001b
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost

(process:12625): GLib-CRITICAL **: g_slice_set_config: assertion `sys_page_size == 0' failed
plasma-desktop(12450)/plasma StatusNotifierItemSource::refreshCallback: DBusMenu disabled for this application
dolphin(12508)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
royroy@localhost ~ $
==================================================================================================
I ran it again with this command "konsole -e tail -f /home/royroy/.xsession-errors" and got a similar message:

QObject::startTimer: QTimer cannot have a negative interval
plasma-desktop(12450)/plasma StatusNotifierItemSource::refreshCallback: DBusMenu disabled for this application
plasma-desktop(12450)/plasma StatusNotifierItemSource::refreshCallback: DBusMenu disabled for this application
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
Qt: Session management error: Could not open network socket
kio_file(13189) kdemain: Starting 13189
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
Qt: Session management error: Could not open network socket
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
Qt: Session management error: Could not open network socket
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost
Qt: Session management error: Could not open network socket
plasma-desktop(12450)/plasma StatusNotifierItemSource::refreshCallback: DBusMenu disabled for this application

I could not get any writes "on the fly" in the terminal when I tried to log out from the desktop using both commands.

@@@@ I did notice something very interesting, however. When I use the Gentoo command "rc-update del xdm default" (which removed xdm from the default runlevel) in order to stop xdm from automatically launching on bootup, I was brought to a prompt when I rebooted, and when I logged in as root at the prompt and used the Gentoo command "/etc/init.d/xdm start" in order to manually start xdm, it finished booting up perfectly and the problem disappeared. So it seems like if xdm is set to automatically launch at boot using the init script (xdm) in /etc/init.d, the problem exists but if I manually launch kdm from the root prompt (which uses the very same init script), the problem goes away. Very interesting.

Thanks for helping me very much.



Roy
=======================================================================================================================

_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost

Either garbage in /etc/hosts or networkmanager changes the hostname after X11 is up.
... or something entirely different, but whatever it is, it is certainly not good.

This is getting more interesting by the minute.

I took a hint from luebking and removed wicd from the default runlevel ( I don't use networkmanager) to prevent it from starting at boot, and viola, the problem went away, even when xdm was set to start automatically.

The error message "_IceTransSocketUNIXConnect: Cannot connect to non-local host localhost" also went away.

Is there something I can change in the hosts file? Everything in the hosts file is commented out except below:

# IPv4 and IPv6 localhost aliases
127.0.0.1 localhost
::1 localhost



Please help me resolve this issue. Please.

All the best,
Roy

wild guess: /etc/hostname is "localhost"?

Hello luebking,

My hostname file in Gentoo is in /etc/conf.d, and this is what it says:

# Set to the hostname of this machine
hostname="localhost"

Try to alter it to st. nice like "MyBox" or whatever.

Hello luebking,

I changed my hostname file to this:

# Set to the hostname of this machine
#hostname="localhost"
hostname="mybox"

and the problem went away ! as well as the error in .xsession-errors !

Thank you for your insight.

Now I would love for you are someone to explain why that made it work (if you don't mind).

All the best,
Roy

PS I did not have to change anything in /etc/hosts for it to work but I changed it anyway and it continued to work:

# IPv4 and IPv6 localhost aliases
127.0.0.1 localhost mybox
::1 localhost

Having "127.0.0.1 localhost.localdomain localhost <actual_hostname>" is a good idea but not absolutely required (iirc systemd hostnamectl even auto-sets this)

What *likely* happens on your side is that you're connecting to a router and using dhcp.
Your clients asks for an IP and says its hostname is "localhost". Since the router wants to manage ip/hostname assignment and prevent hostname clashes in the local net (becomes a real issue with netbios or bonjour/zeroconf/avahi) and a clash with the generic "localhost" name (always resolves the local host....) is überlikely, it will send a new hostname (usually derived from the MAC address of the interface, ie. your network/wifi chip/card) and dh[cpd|client] will inform the system about that (you can try calling "hostname" when the issue is present)

Since X11 is rather a network protocol with attached displayserver, it will continue to contact hostname "localhost" (not the generic "localhost" alias) which can no longer be resolved.

No idea whom to blame here, but having hostname in shape before starting *any* network action is a good idea, so you should prevent it from chaning at runtime.
Since dhcp can take some time (so you'd have to wait, blocking boot) the smart way is to claim a hostname where you know you'll get it (and in a real local network you'd want pre-known, speaking and simple hostnames anyway) - usually distros ask for one at installation.