[kde-freebsd] Re: start kde fails after reboot

Rusty Nejdl rnejdl at ringofsaturn.com
Sat Apr 16 06:54:57 CEST 2011


  

On Sat, 16 Apr 2011 11:52:00 +0700, Gua Chung Lim wrote: 

> Hi
All,
> 
>> Weird... There was also a library lookup failure in your log,
apparently related to nepomuk. If you log into twm or whatever currently
works, then open a terminal and run kdeinit4 and/or some KDE4 program,
do they work?
> 
> In xterm...
> 
> gua at bsdhost:~%
/usr/local/kde4/bin/kdeinit4
> kdeinit4: Shutting down running client.
>
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
>
KDE Daemon (kded) already running.
> kbuildsycoca4 running...
>
kbuildsycoca4(2057)/kdecore (services) KServicePrivate::init: The
desktop entry file "/usr/local/share/applications/kde/koffice.desktop"
has Type= "Application" but no Exec line 
> 
> kbuildsycoca4(2057)
KBuildServiceFactory::createEntry: Invalid Service :
"/usr/local/share/applications/kde/koffice.desktop" 
> kdeinit4: Fatal
IO error: client killed
> kdeinit4: sending SIGHUP to children.
>
klauncher: Exiting on signal 1
> kdeinit4: sending SIGTERM to
children.
> kdeinit4: Exit.
> gua at bsdhost:~%
> 
> And nothing else
happens. I have also tried the others e.g. kdevelop or kcalc.
> They all
don't work.
> 
>> Open the file ~/.kde4/share/config/kwinrc You will
find ( if it is enabled ) a [compositing] section In it you should find
a line "Enabled = True" Change it to "Enabled = False" Then log out then
back in.
> 
> I have tried it. It still doesn't work.
> 
> This is my
analysis. If I'm wrong, please tell me.
> Right after installing from
ports, it works fine.
> I logout from KDE4 and I IMMEDIATELY reboot.
>
After reboot, the binaries are still there.
> And those binaries, for
sure, are not changed across reboot.
> But the subsequent startx
fails.
> So IMHO, there must be something logically changed during
reboot.
> It maybe shutdown process or booting process e.g.
rc.shutdown.
> But all those scripts are default and I did not touch
them.
> I can only trigger it back to the good state by ``make
deinstall''
> and ``make install''.
> During this experiment, I do not
touch anything.
> I use the same tarballs in distfiles, with same gcc,
same system and same libs.
> So recompiling from ports will likely to
produce EXACTLY the same binaries.
> The binaries before and after
``make'' processes are the same.
> So there must be some triggers hidden
in those Makefile(s).
> It could not be env variables.
> csh forks make,
I DON'T think ``make'' can even change env of its parent (csh).
> And I
don't think root env variables can affect env of normal users.
> (I
startx as a normal user not root.)
> It's now far beyond my knowledge.
>

> Any inputs will be highly appreciated.
> 
> Thank you.

Actually, I'm
going the other direction. Something isn't running until you reboot,
maybe hald? Whatever that is, as long as it isn't running, it isn't
conflicting or maybe kde is falling back to something that works on your
system. When you reboot, that process comes up and then kde either can't
use it for whatever reason or it conflicts with something in KDE. 

What
is the contents of your /etc/rc.conf? 

Rusty Nejdl 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-freebsd/attachments/20110415/5df46303/attachment.htm 


More information about the kde-freebsd mailing list