On Fri, 2005-10-21 at 15:05 +0200, Birger Lammering wrote: > Hi Shaya, > this observation might be related to your problem: I had a problem with > the dcopserver during KDE startup. I'm working on a modified KNOPPIX > 4.0.2 with a few Debian-Updates and some additional Unionfs-Branches. > At some point KDE didn't start, giving a message along the lines of: > > The message returned by the system was: > > Could not read network connection /home/username/DCOPserver_hostname__0 > > Please check that the "dcopserver" program is running.
I'm not sure I'm having the same problem, as some dcop stuff does work (i.e. konqueror loads the text editor) > In a failsafe-session the dcopserver said "ICE Connection rejected!", > after kdeinit tried to talk to it. The permissions on all relevant files > in /tmp and ~/ were ok (according to 'ls'). > If I started KDE as root dcopserver worked just fine. I couldn't make > out any files that had unionfs-related permission problems. But my > suspicion is that just this is the cause. > Imho KDE is a bit too complex as a debugging tool. > > All this was happening using several unionfs-snapshots since > snapshot-20051006-0924 up to 1.1.0 - I haven't tried earlier versions. > And this was happening after I fiddled with the unionfs-branches. > The usage/omission of delete=whitout made no difference too... my problems go back to at least september, as I was having a problem then, integrated all the patches since then yesterday to see if they fixed it, but no luck. I'll probably try and do a binary search on it today if I have time. > The solution for me was to re-order some of the ro-unionfs-branches and > to avoid overlapping directory structures in the branches. > => Systems with several branches behave less predictable (wrt > permissions) the more entangled the file systems are... This doesn't > seem to be a new observation. ;-) doesn't seem to be my problem, all I have is a bear "main" directory which is ro, layered below a blank "1" directory which is rw. So all changes will go to "1", without modifying main. _______________________________________________ unionfs mailing list [email protected] http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
