On Mi, 2011-02-02 at 08:27 +0000, Tino Keitel wrote: > On Wed, Feb 02, 2011 at 09:25:47 +0100, Patrick Ohly wrote: > > On Mi, 2011-02-02 at 08:00 +0000, Tino Keitel wrote: > > > I guess I should just use syncevo-http-server --start-dbus-session and > > > trust the script to not leave stale dbus-server --session processes. > > > > Yes, please give it a try and report back if it doesn't work. > > > > > When I do this, I get this: > > > > > > syncevo-http: D-Bus session found (DISPLAY= > > > DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-gRbqTYtIbL,guid=eb2b4568aa8af99d0b0f083d4d490c68), > > > but starting a new D-Bus session as requested > > > > > > I don't know where it gets the old session. It doesn't seem to exist, > > > and the service should be started in a clean environment. > > > > Are you logged into the machine with a running X session? > > > > In that case the script finds the X session and from there the D-Bus > > session. This catches the situation that someone uses the script from > > cron on his desktop, because then he would normally end up with > > Evolution Data Server running twice: once inside the cron session, once > > inside the normal X session. > > It is a headless server and I'm logged in via SSH. A "ps aux | grep > dbus-daemon" shows only the --system daemon.
Is the DBUS_SESSION_BUS_ADDRESS env variable perhaps set anyway, despite not really having that daemon running? After looking at the code that's pretty much what the message above says. The logic I mentioned (look up sessions, find X session) is elsewhere. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
