Bug 54362

Summary:	kded does not start with custom applnk entries
Product:	[Unmaintained] kdelibs	Reporter:	Malte Gell <malte_gell>
Component:	kded	Assignee:	Unassigned bugs mailing-list <unassigned-bugs>
Status:	RESOLVED FIXED
Severity:	crash
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Malte Gell 2003-02-09 21:46:50 UTC

Version:            (using KDE KDE 3.1)
Installed from:    Compiled From Sources
Compiler:          gcc 3.2.1 
OS:          Linux

If you have some custom entries in ~/.kde/share/applnk/ the kded daemon does not start at logging in, no matter if you use startx or via kdm.

The error in ~/.xsession-errors look like this if kded does not start:

_X11TransSocketOpen: socket() failed for local
_X11TransSocketOpenCOTSClient: Unable to open socket for local
_X11TransOpen: transport open failed for local/eingang:0
kded: cannot connect to X server :0.0
ERROR: KUniqueApplication: DCOP communication error!

It may look like a bad configured X, but it has nothing to do with X.

cd ~/.kde/share/ && rm -rf applnk solves the problem, after that kded daemon starts correctly.
I've noticed this error when I wondered why the KDE print manager couldn't be loaded, then I saw that kded wasn't running at all, after deleting ~/.kde/share/applnk now kded is starting again after logging in.

This error is reproducable on my machine. I will try to provide you my ~/.kde/share/applnk/ entries in order to reproduce this error.

Comment 1 Malte Gell 2003-02-10 01:52:58 UTC

I just found a way for simply reproducing this bug:

cd ~/.kde/share/applnk
md Test
cd Test
md justatest.desktop

Then log off KDE and log on again and try ps aux|grep -w kded and you may not
see kded running in that session.
Of course, this "test" is simple and dirty, but it shows that kded seem to have
problems to parse the folder ~/.kde/share/applnk/ correctly and if it fails,
kded won't run.
Malte

Comment 2 Stephan Kulow 2003-03-10 21:07:06 UTC

can not reproduce this. it works fine here. 
Can it be you have a ulimit for open file descriptors? So 
it gets out of file descriptors when it opens your Test 
directory, so it can't open the X socket anymore.

Comment 3 Malte Gell 2003-03-11 15:51:12 UTC

Subject: Re:  kded does not start with custom applnk entries

> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>
> http://bugs.kde.org/show_bug.cgi?id=54362
>
>
> ------- Additional Comments From coolo@kde.org  2003-03-10 21:07

> ------- can not reproduce this. it works fine here.
> Can it be you have a ulimit for open file descriptors? So
> it gets out of file descriptors when it opens your Test
> directory, so it can't open the X socket anymore.


ulimit -Sc 0                # don't create core files
ulimit -Sd unlimited
test "$is" != "ksh" && ulimit -Ss unlimited
ulimit -Sm unlimited

These are the only ulimts set on the system (SuSE 7.3) in /etc/profile, 
but they're all set to unlimited, besides the core file limit, so they 
shouldn't be a problem ?

Comment 4 Waldo Bastian 2003-03-14 23:36:27 UTC

Subject: KDE_3_1_BRANCH: kdelibs/kded

CVS commit by waba: 

CCMAIL: 54362-done@bugs.kde.org
create first the local X socket and start sycoca afterwards.
This fixes the problem with failing kded because of fd limit with huge menu 
structures, when using DNOTIFY support.
(backport)


  M +3 -3      kded.cpp   1.75.2.1


--- kdelibs/kded/kded.cpp  #1.75:1.75.2.1
@@ -713,9 +713,9 @@ int main(int argc, char *argv[])
      Kded *kded = new Kded(bCheckSycoca); // Build data base
 
-     kded->recreate();
-
      signal(SIGTERM, sighandler);
      signal(SIGHUP, sighandler);
      KDEDApplication k;
+
+     kded->recreate();
 
      if (bCheckUpdates)

Comment 5 Malte Gell 2003-03-17 17:29:35 UTC

Thanx for the patch, this bug is gone now. It works.