I'm having a problem that I thus far have been unable to track down. Details are in the URL. I'd definitely appreciate any help you can give in tracking it down, because every kde app on my system is broken due to it. Portage 2.1.1-r1 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.18-gentoo-r1 x86_64) ================================================================= System uname: 2.6.18-gentoo-r1 x86_64 AMD Opteron(tm) Processor 152 Gentoo Base System version 1.12.5 Last Sync: Fri, 20 Oct 2006 12:50:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17-r2 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.16 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=opteron -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="-1" FEATURES="autoconfig distlocks ignorecvs metadata-transfer parallel-fetch sandbox sfperms strict userfetch userpriv usersandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://gentoo.chem.wisc.edu/gentoo/" LC_ALL="en_US.utf8" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/opt/overlay/mine /usr/portage/local/layman/musicbrainz /usr/portage/local/layman/my-lu_zero /usr/portage/local/layman/my-xfce /usr/portage/local/layman/sunrise" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="amd64 S3TC X a52 aac acpi acpi4linux adns alsa amr ao aoss aotuv ared aredmem asf audiofile bcp berkdb bitmap-fonts blender-game branding bzip2 cairo calendar cap caps cddb cdparanoia cli cpudetection crypt crypto css cups curl dbus divx djbfft dlloader dmi dri dts dv dvb dvd dvdr dvdread edl elibc_glibc encode ethereal exif exim exo extensions faac faad fam ffmpeg fftw firefox fla flac fontconfig freetype gb gd gd-external gdbm gecko-sdk geoip gif gimp ginac glade glgd glitz glut gmedia gmp gnomedb gnutls gpgme gphoto2 graphviz gtk gtk2 gtkhtml hal howl ieee1394 imagemagick imap imlib imlib2 innodb input_devices_evdev input_devices_keyboard input_devices_mouse javascript jikes jpeg junit kde kdeenablefinal kdehiddenvisibility kernel_linux lcms lesstif libgda libsamplerate linguas_en lirc lirc_devices_hauppauge live logitech-mouse lua lzo mad maildir mailwrapper matroska md5 mime ming mjpeg mng mozcalendar mozdomi mozilla moznocompose moznoirc moznomail mozsvg mp3 mp4 mpeg mpeg4 mplayer mpm-prefork music musicbrainz mythtv ncurses nethack network new-login no-old-linux no-seamonkey nocardbus nocd nowin nptl nptlonly nsplugin nvidia offensive ogg oggvorbis ooo-kde openal openexr opengl oss pam panel-plugin pcap pcre pda pdf perl physfs pic plotutils png posix povray ppds print python qa qhull qt3 quicktime quotes readline reflection rtc samba sdk sdl session slp smime snmp sockets speex spell spl sqlite ssl startup-notification stroke svg tcpd tetex tga theora thumbnail thunar thunar-vfs tidy tiff truetype truetype-fonts type1-fonts udev ungif unicode usb userland_GNU utempter v4l v4l2 vhosts video_cards_nvidia videos vim-with-x vorbis wmp x264 xanim xext xinetd xml xml2 xorg xosd xpm xrandr xscreensaver xv xvid xvmc yaz yv12 zeroconf zip zlib zvbi" Unset: CTARGET, INSTALL_MASK, LANG, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
You might get some valuable information from something like this: startx 2> startx.log And see what type of errors you see from all of KDE's programs starting. My hunch is that you either don't have read/write permission to your home directory (namely /home/username/.DCOP* ) or you don't have read/write permissions to /tmp.
Thanks for the response. Both good hunches. Unfortunately: -rw-r--r-- 1 mike mike 54 2006-10-20 13:29 /home/mike/.DCOPserver_brust__0 lrwxrwxrwx 1 mike mike 31 2006-10-20 13:19 /home/mike/.DCOPserver_brust_:0 -> /home/mike/.DCOPserver_brust__0 drwxrwxrwt 17 root root 664 2006-10-20 13:30 /tmp drwxrwxrwt 2 root root 528 2006-10-20 13:29 /tmp/.ICE-unix As for the logs, yep, it's dumping them (especially hard, since i did +debug on kdelibs) but they don't print anything obvious about what's going on.. they're just not properly registering with dcopserver. They show up on the list using the dcop and kdcop clients, but if you actually try to connect to them then you can't, and when you use the apps you can see they're not talking to anyone else. Apps like kmail and ktorrent refuse to even start up if they can't talk to dcopserver.
Root owns /tmp/.ICE-unix, and since it's sticky others can't overwrite and delete it. Delete that file as root and restart X as your normal user.
It was my understanding that those were the proper perms for it (that's what kde recommends). I changed it, though: drwxrwxrwx 2 mike mike 88 2006-10-20 14:45 /tmp/.ICE-unix still no go :/ mike@brust:~> ps aux | grep dcopserver | grep -v grep mike@brust:~> akregator DCOPClient::attachInternal. Attach failed Could not open network socket DCOPClient::attachInternal. Attach failed Could not open network socket kdeinit: Launched DCOPServer, pid = 21958 result = 0 mkdir: Owner of /tmp/.ICE-unix should be set to root DCOP: register 'anonymous-21958' -> number of clients is now 1 DCOP: unregister 'anonymous-21958' kdeinit: Launched KLauncher, pid = 21962 result = 0 DCOP: register 'klauncher' -> number of clients is now 1 kdeinit: opened connection to :0.0 DCOP: new daemon klauncher kdeinit: Launched KDED, pid = 21963 result = 0 DCOP: register 'kded' -> number of clients is now 1 DCOP: unregister 'kded' DCOP: register 'kded' -> number of clients is now 1 DCOP: register 'anonymous-21963' -> number of clients is now 2 kio (KDirWatch): Available methods: Stat, Inotify kdecore (KStartupInfo): creating: brust;1161380891;883829;21964_TIME0:kded kded: ERROR: Communication problem with kded, it probably crashed. DCOP: unregister 'anonymous-21963' kdeinit: PID 21963 terminated. DCOP: register 'akregator' -> number of clients is now 2 kdecore (KStartupInfo): creating: brust;1161380891;958621;21955_TIME0:akregator DCOP: register 'anonymous-21954' -> number of clients is now 3 akregator: ERROR: Communication problem with akregator, it probably crashed. DCOP: unregister 'anonymous-21954' kio (KSycoca): Trying to open ksycoca from /var/tmp/kdecache-mike/ksycoca kio (KSycoca): Trying to open ksycoca from /var/tmp/kdecache-mike/ksycoca kio (KDirWatch): Added Dir /home/mike/.kde/share/servicetypes [KDirWatch-1] kio (KDirWatch): Added Dir /usr/kde/3.5/share/servicetypes [KDirWatch-1] [... blah blah snip ...] kio (KDirWatch): Added Dir /usr/kde/3.5/share/applications/kde [KDirWatch-1] kio (KDirWatch): Added Dir /usr/share/applications [KDirWatch-1] kio (KDirWatch): Added Dir /usr/share/applications/kde [KDirWatch-1] kio (KDirWatch): Global Poll Freq is now 500 msec kio (KDirWatch): Started Polling Timer, freq 500 kio (KDirWatch): Setup Stat (freq 500) for /usr/share/applications/kde kio (KDirWatch): Added Dir /home/mike/.kde/share/apps/kconf_update [KDirWatch-2] kio (KDirWatch): Added Dir /usr/kde/3.5/share/apps/kconf_update [KDirWatch-2] DCOP: new daemon kded mike@brust:~> dcop DCOP: register 'anonymous-21975' -> number of clients is now 2 kded klauncher akregator DCOP: unregister 'anonymous-21975' mike@brust:~> dcop akregator DCOP: register 'anonymous-21976' -> number of clients is now 2 Application 'akregator' not accessible DCOP: unregister 'anonymous-21976' mike@brust:~> dcop kded DCOP: register 'anonymous-21977' -> number of clients is now 2 Application 'kded' not accessible DCOP: unregister 'anonymous-21977' mike@brust:~> dcop klauncher DCOP: register 'anonymous-21978' -> number of clients is now 2 Application 'klauncher' not accessible DCOP: unregister 'anonymous-21978'
Well, there's other tmp files too that KDE wants /tmp/kde-username for example. I recommend stopping X, removing all files in tmp (if that won't cause some kind of problem for you) and then trying to restart X.
Same with /var/tmp, by the way
Completely killed the contents of /tmp and /var/tmp (including dotfiles) (don't worry, i'm not blindly following instructions- I wouldn't have done it if I shouldn't have ;)) Still no go. (btw, for faster turnaround, i'm novas0x2a on freenode, if you're into that sort of thing)
The user is trying to use it under xfce and emerged some packages of kdebase, not even the whole kdebase-meta. My supposition is that some dcop functions could have been moved to another packages while dcop ebuild still has not it as dependancy. Also the user reported in freenode this log configuring every kde package (when not using confcache): ....... checking if kdepasswd should be compiled... yes configure: creating ./config.status wrong input (flag != 4) at admin/conf.change.pl line 117, <> line 1363. config.status: creating Makefile I also asked the user to report here the output of revdep-rebuild --pretend --ignore , if any.
I'm afraid that it did not fix the problem. I'm installing the meta packages for everything else I have installed, but I do not believe that will solve the problem, either. Remember: everything works just fine as root. It only fails with user accounts.
No, the issue could be cause you were missing some kdebase package. Other ones aren't for sure. Working as root? Do you use to login to the X desktop as root? that's not an option in Kde, kdm hides root-user automatically.... This is the issue. As pointed out in: http://babelfish.altavista.com/babelfish/tr?lp=de_en&url=http%3A//www.supernature-forum.de/vbb/alles-rund-um-linux/52474-kde-und-dcop-server-could-not-open.html then in http://linuxfromscratch.org/pipermail/blfs-support/2001-October/011862.html and in http://lists.kde.org/?l=kde-devel&m=97032596404456&w=2 kde apps have their way to use root privileges (kdesu) , loading them with root privileges in any other way causes issues (at least this is until kde 4, that doesn't uses DCOP anymore but dbus....)
I never log in as root, but i do su - to root. I don't use kdm. My network socket problem has to be caused by something else, because the permissions on .DCOP* are correct. These are now installed: kdebase-meta kdenetwork-meta kdeaddons-meta kdegames-meta kdegraphics-meta kdemultimedia-meta kdepim-meta and kdeutils-meta are still installing, but neither of those is a required package. However, my argument is that it is extremely unlikely that this problem could be caused by a missing package, because all of the kde programs work perfectly when i su to root and then run them. (su - creates a login shell, so the problem that sudo creates does not happen to me) For example, take the command line "dcop" client. dcop is in kdelibs, and therefore does not depend on anything outside kdelibs. mike@brust:~> dcop DCOP: register 'anonymous-9710' -> number of clients is now 1 kded klauncher DCOP: unregister 'anonymous-9710' mike@brust:~> dcop klauncher DCOP: register 'anonymous-11627' -> number of clients is now 1 Application 'klauncher' not accessible DCOP: unregister 'anonymous-11627' This is the same with every kde application. They show up in the list, but they are not accessible, and the processes are in an interruptible sleep. But when I su - to root, every program works as expected. The permissions on /tmp/.ICE-unix, ~/.DCOP*, ~/.Xauthority, /var/tmp/kde*-mike, all of ~/.kde, everything, are all ok.
I'm saying that you shouldn't "su to root and run them", kde apps need you to use kdesu (and only kdesu, no su, no gnomesu, no sudo) if you want to run them with root privileges and not start a dcop as root....... Normal behaviour is: as user dcop works fine, as root dcop won't work and gives : "ERROR: Couldn't attach to DCOP server!" (I tried after starting a couple apps with kdesu) So dcop should be usable only at user-level. The fact that you have those inverted IS pointing to some kind of privilege issue.
Also in the second link I gaved you they suggest to check permissions (not only chmod, you may have to use chown!!!!) of /tmp/mcop-<users> /tmp/kde-<user> and /tmp/ksocket-<users> , not those you checked.
Re comment #12 a new dcopserver runs as each user who needs it (this is a multi-user system, after all). A user account cannot use anyone else's dcop. So of course a user cannot use a dcopserver started by root. Root, however, can use a dcopserver started by root. When root starts a dcopserver, he gets a /tmp/kde-root, /tmp/kde-ksocket, etc, of his very own. Re comment #13 /tmp/mcop-<users> /tmp/kde-<user> and /tmp/ksocket-<user> are all fine. Quoting http://bugs.kde.org/show_bug.cgi?id=135977#c11 "To check the permissions, I ran find / on this system and a working one. I then took the intersection of those sets. I then stat'd every file in that list on both machines, and compared the permissions. There were no significant differences." I made very sure that every KDE-created directory I knew about was in that list.
To quote everything else important from the original bug: "I've checked permissions in both my home dir and /tmp/k*-$USER. /tmp/.ICE-unix is all in order, as is ~/.DCOPserver*. I assumed it was a permissions problem because the problem persists across all user accounts, but root has no problems. I've also tried moving away my ~/.kde, but that changed nothing." "Fails with a newly-created user. I've also straced kdeinit, dcopserver, and kmail, looking for access denied- haven't found anything suspicious." To put this to rest: mike@brust:~> ls -d /tmp /tmp/kde-mike /tmp/ksocket-mike /tmp/.ICE-unix ~/.kde ~/.DCOPserver_brust_* /tmp/.mcop* /var/tmp /var/tmp/kdecache-mike -rw-r--r-- 1 mike mike 54 2006-10-21 14:56 /home/mike/.DCOPserver_brust__0 lrwxrwxrwx 1 mike mike 31 2006-10-21 05:58 /home/mike/.DCOPserver_brust_:0 -> /home/mike/.DCOPserver_brust__0 drwx------ 3 mike mike 168 2006-09-09 14:57 /home/mike/.kde drwxrwxrwt 11 root root 480 2006-10-21 15:05 /tmp drwxrwxrwt 2 root root 248 2006-10-21 14:56 /tmp/.ICE-unix drwx------ 2 mike mike 72 2006-10-21 05:49 /tmp/kde-mike drwx------ 2 mike mike 832 2006-10-21 14:57 /tmp/ksocket-mike drwxrwxrwt 6 root root 160 2006-10-21 06:05 /var/tmp drwx------ 4 mike mike 152 2006-10-21 04:46 /var/tmp/kdecache-mike And yes, my /tmp/.ICE-unix permissions are correct. They should be 1777 and owned by root.
Dcop is running fine on any other machine but that, if it's not a permission/configuration issue (but I would expetc issues from that system, CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" it's not so sane) then it could be only: a) incompatibility with xfce, dcop bug. b) incompatibility with dcop, xfce bug. None of them is incompatible with portage as xfce had updates in portage dated 6-oct-2006, just 4 days before your first report. Sorry I haven't any xfce + kde apps system to check, try to ask to xfce maintainers if they can use dcop actually.
ops, sorry, too late night here, *expect and *14 days.
I'm confused. What's odd about my CONFIG_PROTECT? It comes from /etc/env.d/45kdepaths-3.5 in kdelibs and /etc/env.d/10xkeyboard-config in x11-misc/xkeyboard-config, a dep of xorg-server. As for the system being "not so sane," I've been running with this same setup (xfce with kde packages) for more than four years, and this is the first time there has been a problem with it.
Also, I tried running KDE in the normal fashion (exec startkde and all that) and it failed- it sat at the startup splash screen for a long time, waiting for "services" to start, until I finally gave up and killed X. So, clearly, it is not an xfce problem at all. I was hoping the KDE developers could lend their knowledge of the system to solving my somewhat unusual problem, but since it is a "configuration issue", apparently, it is not their problem.
You're right, that comes from kdelibs package, I'll have to ask my teammate if that is something wanted and why (that could be as well my fault to not know it). We're unable to replicate your issue, nobody else has it (actually, but if kde was not starting for anyone I bet we would already had plenty of reports), so what can we think about it? Can a bug in the sources exists on just 1 system and not on every other system on earth? No, or better: it never happened until now. We have no other choiches to wait for other reporters with more infos to allow us to replicate, or pointing to something specifically in your machine that could have caused this, because you insist saying that your machine wasn't "riced" at all, then the only option is to wait.
I'd appreciate it very much if you solved this for me. I'm willing to give someone a user-level login to aid in this. Let me know (novas0x2a on freenode) when you're available and willing.
I tell you what- I'm going to set a bounty on this. The first person to solve my bug, tell me what the problem was, and provide a solution, will win the bounty. (Solutions that involve just reinstalling my system will not be accepted. I need to know what is happening, so I can fix it if it ever happens again.) I will send US$20 to you, Gentoo, KDE, or the charity or open-source project of your choice. Alternately, if you live in Silicon Valley, California (USA) I will buy you a round or two of your beverage of choice. I know it's not much, but I don't have much to give.
Ouch! I wasn't enough clear..... your isn't a bug.And we aren't asking for money. It can have possible causes: -wrong permissions (you rechecked so shouldn't be) -wrong executables (corruption on your hd or you didn't updated some etc files when it was needed) , in this case you should re-emerge --oneshot qt, kdelibs and every package in kdebase-meta. And hope to not find other disk corruption. -messed system (due to mixing gcc-3.x code with gcc-4.x code or similar), only try to fix that is emerge -e world (long). -badly wrong or missing config file somewhere (for this only human intervent can do something, only try is to create another user -not-root!- and try to start kde with the new user, better if with startx to get some log, but even this can't cover all the possible causes). But still, you're on your own in your tests. Just a question, personal curiosity, did you use sphinx3? And, if so, did you rebuilt your system after the collision report? (there was an issue about sphinx3 overwriting the libutils of glibc, some week ago, just trying to guess).
> wrong permissions (you rechecked so shouldn't be) Correct. > wrong executables (corruption on your hd or you didn't updated some etc files > when it was needed) , in this case you should re-emerge --oneshot qt, kdelibs > and every package in kdebase-meta. And hope to not find other disk corruption. I've rebuilt everything multiple times, always with the cflags listed in my emerge --info, and at least once with every one of (USE="kdehiddenvisibility debug", USE="kdehiddenvisibility -debug" USE="-kdehiddenvisibility debug" USE="-kdehiddenvisibility -debug") In addition, i've run short and long SMART disk checks and run every test that it is safe for reiserfsck to run. So I'm pretty sure it's not disk corruption. > messed system (due to mixing gcc-3.x code with gcc-4.x code or similar), only > try to fix that is emerge -e world (long). When I switched to gcc-4.1.1, the first thing I did was rebuild everything with emerge -e world, so I'm pretty sure that's not the problem. > badly wrong or missing config file somewhere (for this only human intervent > can do something, only try is to create another user -not-root!- and try to > start kde with the new user, better if with startx to get some log, but even > this can't cover all the possible causes). As I mentioned before, it fails with every user account, even newly-created ones with empty home directories. Every user fails, and root has no problems. > But still, you're on your own in your tests. This is why I'm offering money. Because I've tried everything I could think of, and have come up dry. I'm asking for someone to log in to my computer and poke around, to see if I've just completely missed something. I'm offering some money to compensate someone for taking that extra step. I'm aware that there's not much more you can do from where you are, unless I let you log in and hopefully spot something silly that I've missed. One of the reasons I'm so desperate to find the cause of this problem is, if I don't find the cause, I will have to switch away from KDE- probably forever. If I don't know why this happened, then it could happen again. And I can't risk that. I really like the KDE applications I use, though, and I don't really want to stop using them. So it's worth money to me to get this fixed. > Just a question, personal curiosity, did you use sphinx3? And, if so, did you > rebuilt your system after the collision report? (there was an issue about > sphinx3 overwriting the libutils of glibc, some week ago, just trying to > guess). Nope, never installed it before, or heard of it before today.
This is , for example, one of the possible causes: some library symbolik links that are broken : http://lists.suse.com/archive/suse-kde/2003-Jun/0025.html you can try to run this script in /usr/lib and then check if there's something inside ~/brokenlink.txt : #!/bin/bash echo "links that are broken:" > ~/brokenlink.txt find -type l > ~/liblinks.txt exec 6<~/liblinks.txt # read until end of file while read -u 6 dta do readlink "$dta" || echo "$dta" >> ~/brokenlink.txt done # close file exec 6<&- if [ -e ~/liblinks.txt ]; then rm ~/liblinks.txt fi
Auch, sorry I losed a "-e" somewhere in the hurry: readlink -e "$dta" || echo "$dta" >> ~/brokenlink.txt
I just solved it. Or, rather, I'm pretty sure about the cause. I had a lot of cross-compilers installed. Just to make sure, I removed almost all of them (all but avr). I then tried to compile kdelibs, and I got a failure due to a missing header that was supposed to be installed with linux-headers (linux/limits.h). For some reason, removing the cross-compilers removed that file. Somehow my cross-compiler system got mixed in with my regular system. I reinstalled linux-headers, and then recompiled kdelibs, and the problem is gone. I guess I was compiling with linux-headers for a different arch, or something, before. Thanks, Matteo, for planting the seed of the idea :)
For next risky/strange installs : FEATURES="collision_protect" should help avoiding that a package overwrites files from another package.
Yeah, I've been meaning to turn that on for a while- once bonsaikitten's reports are mostly fixed (about spurious collisions, etc) I'm definitely turning it on.
