Hello!
Has anyone experienced segmentation faults with kicker (kde panel)? It only
happens when I quit KDE. Also sending SIGTERM or stopping kicker with dcop
call results in the same - kcrash is invoked. If I just start kicker and send
SIGTERM to it - fine. If I start kicker and browse the K menu for a few
seconds, and then terminate, it fails to shutdown cleanly... I run updated
Fedora Core 4, and I thought it might be an issue with updates (I have
upgraded to KDE 3.4.3 from kde-redhat project). However after I install
clean, original FC4 on a different disk - everything is the same - kicker
crashing...
Perhaps someone helps...
Anyway thanks. I solved a lot of KDE bugs, these are my latest researches :)
**** KDE root-level apps failure ****
If you have noticed, running root-level priveledge applications from KDE (via
kdesu, userhelper and so on) is buggy, results in X server connection
rejects, or doesn't work at all. Try running KDE control center, then going
to, for example, System Fonts and choosing administration level (root). After
being prompted for password, you might see that you haven't achieved the root
menus, but have been put back to user menus with no root options.
This happens because /tmp/kde-$USER/ksycoca symlinks have been removed by
rc.sysinit script on system (re)boot. And if previously KDE system
configuration cache for root had been created, the symlink is NOT restored,
but is essential for apps to run! At least
removing /var/tmp/kdecache-root/ksycoca will make the kbuildsycoca maek the
links again. Running kbulidsycoca --noincremental should also help. However
there is more elegant solution without modifications of any RPM-produced
files. Put the following to your /etc/rc.d/rc.local startup script.
----------------------------------------------
for i in /var/tmp/kdecache-*; do
a=${i#*-}
[ -e /tmp/kde-$a/ksycoca ] && continue
[ -e $i/ksycoca ] || continue
grep -q ^$a: /etc/passwd || continue
install -d -m 0700 -o `id -u $a` -g `id -g $a` /tmp/kde-$a
ln -s $i/ksycoca /tmp/kde-$a/ksycoca
done
----------------------------------------------
Alternatively just alter the rc.sysinit script so that it won't touch
important stuff.
**** KDE 3.4.3 (from kde-redhat project) kppp bug ****
If you have problem as I used to have - KPPP fails to update /etc/resolv.conf
after a connection has been established, here is the solution. Make a
script in /root/bin/kppp-compat.sh containing:
----------------------------------------------
PATH=/usr/bin:/bin
REALDEVICE=$1
LOGDEVICE=$6
umask 022
case "`basename $0`" in
ip-up.local)
if [ "$REALDEVICE" = "ppp0" -a -z "$LOGDEVICE" ]; then
grep -v "KPPP-compat" /etc/resolv.conf >/etc/resolv.conf-
(for i in $DNS1 $DNS2; do
fgrep -q $i /etc/resolv.conf || echo "nameserver $i # KPPP-compat"
done
cat /etc/resolv.conf-) >/etc/resolv.conf
[ -f /var/lock/subsys/nscd ] && /usr/sbin/nscd -i hosts
fi
;;
ip-down.local)
if [ "$REALDEVICE" = "ppp0" -a -z "$LOGDEVICE" ]; then
[ -f /etc/resolv.conf- ] && mv -f /etc/resolv.conf- /etc/resolv.conf
[ -f /var/lock/subsys/nscd ] && /usr/sbin/nscd -i hosts
fi
;;
*)
echo "What are you doing?!"
exit
esac
----------------------------------------------
The scripts flushes the NSCD cache as well, as KPPP fails to do it. Now make
symlinks to this script from /etc/ppp/ip-up.local and /etc/ppp/ip-down.local.
Good on ya!
