Who starts sync-engine?

Post by Vasco Steinmetz
Hi,
I know this question is a bit off-topic for this list, but I'd like to know how by whom sync-engine is supposed to be started?
- Should [ov]dccm start it?
- Is there a udev rule available?
- Shouldn't e.g. KitchenSync start it?
- Or one of the trayicon apps?
Whatever way it should honor the currently logged in desktop-user.
Currently I'm starting it in a shell but I'd like to have it start automatically when I put my WM6 device into the cradle.
The wiki is a but unclear on this point.
Cheers,
Vasco

The current way is just to start it in a shell. There is no magic. For
now (if you are using the SVN version) i suggest adding it to your
session.

Perhaps this is something Mark will address as part of hal-dccm?

I prefer this kind of thing not to be implemented in kitchensync,
though that is probably where the opensync people would put it. Doing
that means that multisync, gnome-sync and any other opensync client
would have to reimplement it.

John

Mark Ellis

2007-12-27 10:08:06 UTC

I am blank when it comes to sync-engine, having a WM2003 device I have
not been able to play with it (yet...)

Entering speculation mode.....

It needs to run as the user, not root, correct ? Can't just fire it up
from hal when a device connects then, we don't know what user wants it.

Post by John Carr
I prefer this kind of thing not to be implemented in kitchensync,
though that is probably where the opensync people would put it. Doing
that means that multisync, gnome-sync and any other opensync client
would have to reimplement it.
John

Sounds like it should be started by trayicon or something similar. Isn't
there a dbus interface ? Couldn't we configure dbus to fire it up when
something attaches to the service ? John said he was adding a fix for
when odccm and/or a device was not present, should it just go in the
session startup ?

Mark

John Carr

2007-12-27 12:25:37 UTC

Wearing my cross device, cross distro, working together hat: Really
reluctant to back anything trayicon related. IMO, in the same way that
there is opensync there should be one tray icon system manager 'thing'
that we plug into. Right now gnome-phone-manager is probably the
closest to that...

I like the idea of dbus activation, and using HAL to automatically
close sync-engine when the device is unplugged, but am not how the
device will cope if it is plugged in and the HTTP server for AirSync
is not responding straight away.

John

Dr J A Gow

2007-12-27 12:44:45 UTC

Post by John Carr
I like the idea of dbus activation, and using HAL to automatically
close sync-engine when the device is unplugged, but am not how the
device will cope if it is plugged in and the HTTP server for AirSync
is not responding straight away.

One doesn't need to close sync-engine when a device is unplugged - or
restart it when a device is plugged in. The problem is starting it the
first time - once it is started it can be left running throughout the
session. I am looking at some modifications to sync-engine to allow it
to fork itself into the background and log to a file - all that has to
happen then (as with now) is for the user to include it in a suitable
startup file. Thanks to a patch from Guido Diepen sync-engine will also
now start cleanly in the absence of a running odccm and pick up the
connection when odccm comes alive.

If we make an init.d script for odccm (so it starts as root: I'll do a
quick one for SuSE if you like and pop it in the odccm tree) and place
the call to sync-engine in a user's startup file for whatever
environment is chosen, then everything should work.

All we need to do now is to find a way to terminate OpenSync cleanly if
the sync-engine is not running or a device is not connected. This should
be easy in OpenSync 0.3x but may be troublesome in the earlier releases.
I am working on this.

There are some remaining error-handling issues in sync-engine which
require a restart of sync-engine to clear (e.g. RAPI call
failure/timeout). Once these are cleared sync-engine should run happily
in the background.

John.

John Carr

2007-12-27 13:11:01 UTC

Post by Dr J A Gow

One doesn't need to close sync-engine when a device is unplugged - or
restart it when a device is plugged in. The problem is starting it the
first time - once it is started it can be left running throughout the
session. I am looking at some modifications to sync-engine to allow it
to fork itself into the background and log to a file - all that has to
happen then (as with now) is for the user to include it in a suitable
startup file. Thanks to a patch from Guido Diepen sync-engine will also
now start cleanly in the absence of a running odccm and pick up the
connection when odccm comes alive.
If we make an init.d script for odccm (so it starts as root: I'll do a
quick one for SuSE if you like and pop it in the odccm tree) and place
the call to sync-engine in a user's startup file for whatever
environment is chosen, then everything should work.
All we need to do now is to find a way to terminate OpenSync cleanly if
the sync-engine is not running or a device is not connected. This should
be easy in OpenSync 0.3x but may be troublesome in the earlier releases.
I am working on this.
There are some remaining error-handling issues in sync-engine which
require a restart of sync-engine to clear (e.g. RAPI call
failure/timeout). Once these are cleared sync-engine should run happily
in the background.
John.

While that would work, are we happy having 2 programs resident all the
time, even when they are not needed? I personally hardly ever care
about syncing and would no doubt be bothered that I have these extra
programs running for the once or twice a week task of syncing. Though
I don't think they'll dent the 2gb of RAM in this machine, its still
resources being used that don't need to be. In the long run i'd only
accept this approach if we took 3 steps: Minimize memory used,
minimize any timer based activity (waking up when a device isnt even
attached is just wasting my laptops battery) and make sure that the
ports are only open on the device interfaces (vdccm was exploitable,
if we bound to a public facing interface like my wifi card i would be
very afraid). Of course these are all hypothetical and just random
brain farts...

I believe there are already init scripts for odccm floating around -
one from Mark, one from Jonnylamb, and there is a third floating
around the ubuntu forums...

John

Mark Ellis

2007-12-27 13:27:28 UTC

Post by Dr J A Gow

One doesn't need to close sync-engine when a device is unplugged - or
restart it when a device is plugged in. The problem is starting it the
first time - once it is started it can be left running throughout the
session. I am looking at some modifications to sync-engine to allow it
to fork itself into the background and log to a file - all that has to
happen then (as with now) is for the user to include it in a suitable
startup file. Thanks to a patch from Guido Diepen sync-engine will also
now start cleanly in the absence of a running odccm and pick up the
connection when odccm comes alive.
If we make an init.d script for odccm (so it starts as root: I'll do a
quick one for SuSE if you like and pop it in the odccm tree) and place
the call to sync-engine in a user's startup file for whatever
environment is chosen, then everything should work.
All we need to do now is to find a way to terminate OpenSync cleanly if
the sync-engine is not running or a device is not connected. This should
be easy in OpenSync 0.3x but may be troublesome in the earlier releases.
I am working on this.
There are some remaining error-handling issues in sync-engine which
require a restart of sync-engine to clear (e.g. RAPI call
failure/timeout). Once these are cleared sync-engine should run happily
in the background.
John.

While that would work, are we happy having 2 programs resident all the
time, even when they are not needed? I personally hardly ever care

Two programs ? Do you mean *dccm and sync-engine ? Having this split
seems like a good idea to me. *dccm is solely concerned with access to
the device, irrespective of whether you want file access, syncing, etc.
Sync-engine is concerned with one aspect of a connected device ie.
syncing. Is this what you meant ?

Post by John Carr
about syncing and would no doubt be bothered that I have these extra
programs running for the once or twice a week task of syncing. Though
I don't think they'll dent the 2gb of RAM in this machine, its still
resources being used that don't need to be. In the long run i'd only
accept this approach if we took 3 steps: Minimize memory used,
minimize any timer based activity (waking up when a device isnt even
attached is just wasting my laptops battery) and make sure that the
ports are only open on the device interfaces (vdccm was exploitable,
if we bound to a public facing interface like my wifi card i would be
very afraid). Of course these are all hypothetical and just random
brain farts...

Hal-dccm will only run when a device is connected. I agree that it would
be nice to only kick off sync-engine in a similar way, but I do think it
should be a user session based action, rather than a system one.

Mark

John Carr

2007-12-27 13:51:27 UTC

Post by John Carr
While that would work, are we happy having 2 programs resident all the
time, even when they are not needed? I personally hardly ever care

Yes Mark. John's version of events had odccm and sync-engine running
all the time. Or to be specific: odccm is running all the time and
sync-engine is running all the time a user is logged in. If I don't
plan to connect my device then those programs are using resources that
they need not be using. That is what I meant.

Agreed. D-bus activation would be one way to achieve that - when the
sync plugin attempts to talk to sync-engine over dbus, sync-engine is
started by the dbus session daemon (therefore under the correct user
session). But i'm not sure how that would hurt sync-engine (hence my
original e-mail) - i suspect it wouldn't cope with it as the device
will likely try to sync in the background and the AirSync server just
won't have been started..

John

Mark Ellis

2007-12-27 16:13:10 UTC

Post by John Carr
While that would work, are we happy having 2 programs resident all the
time, even when they are not needed? I personally hardly ever care

Good, I agree.

Ah ok, my lack of sync knowledge is showing here. I had assumed the
device wouldn't try to sync until signalled from the host side, ie
sync-engine, in which case we would have all the time in the world to
start up whatever is required. I take it this is not the case.

Mark

Dr J A Gow

2007-12-27 17:12:21 UTC

Post by John Carr
Agreed. D-bus activation would be one way to achieve that - when the
sync plugin attempts to talk to sync-engine over dbus, sync-engine is
started by the dbus session daemon (therefore under the correct user
session). But i'm not sure how that would hurt sync-engine (hence my
original e-mail) - i suspect it wouldn't cope with it as the device
will likely try to sync in the background and the AirSync server just
won't have been started..

The device won't sync until the partnership is set up and the RAPI
sync-resume command issued (i.e. sync-engine has initialized). So we
should be OK waiting.

John.

John Carr

2007-12-27 17:40:43 UTC

Post by Dr J A Gow
The device won't sync until the partnership is set up and the RAPI
sync-resume command issued (i.e. sync-engine has initialized). So we
should be OK waiting.

This is the bit i wasn't so sure about, particularly in the context of
the triggerconnection program which was merged in to odccm. This is
good to know, and adding dbus activation should be a simple as
shipping a dbus .service file, along the lines of this:

http://svn.gnome.org/svn/conduit/trunk/data/org.conduit.service.in

Though i presume @bindir@ would be populated differently for a
setup.py based installation. This fits in for jagow as well. In his
case, sync-engine starts with his session so org.synce.whatever is
available and dbus activation never has to do anything.

John

Dr J A Gow

2007-12-27 18:00:41 UTC

Post by Dr J A Gow
The device won't sync until the partnership is set up and the RAPI
sync-resume command issued (i.e. sync-engine has initialized). So we
should be OK waiting.

This is the bit i wasn't so sure about, particularly in the context of
the triggerconnection program which was merged in to odccm. This is
good to know, and adding dbus activation should be a simple as
http://svn.gnome.org/svn/conduit/trunk/data/org.conduit.service.in
setup.py based installation. This fits in for jagow as well. In his
case, sync-engine starts with his session so org.synce.whatever is
available and dbus activation never has to do anything.

Is it worth my while popping some code in sync-engine to allow it to run
once and then terminate: i.e. run, allow a device to be connected, and
then when the device is disconnected shut down and exit. I could do this
either with a config.xml parameter or a command line switch - which
would be preferred?

John.

Mark Ellis

2007-12-27 13:17:54 UTC

I'm not plugging trayicon per se, just something that is running on
login as the user that can see a device plugged in and kick off
sync-engine.

Don't know enough (anything) about airsync to say. Sync-engine could
listen to hal events to shut itself down, or just shut down a connection
to that device, but the startup part is a little foggier.

Mark

Richard Alimi

2007-12-24 04:13:50 UTC