On Fr, 2011-03-18 at 15:01 +0000, Patrick Ohly wrote: > On Fr, 2011-03-18 at 14:57 +0000, David Bremner wrote: > > On Tue, 15 Mar 2011 13:27:03 +0100, Patrick Ohly <patrick.o...@intel.com> > > wrote: > > > > > My current thinking is to solve the problem in syncevo-dbus-server > > > locally, without support by the package manager: > > > * at startup, determine a list of all shared libraries loaded into > > > memory (/proc/self/maps) > > > * set up change notifications for these files > > > * when triggered *and* idle, restart the daemon > > > > I'm certainly in favour of having things done without the package > > manager ;). Did you consider some kind of check done by the client > > (e.g. syncevolution cli tool) saying hey dbus server, I am version X, > > are you new enough? > > That won't solve the problem when syncevo-dbus-server is running > permanently to execute regular time-based syncs. In that case files will > be updated underneath the daemon, causing it to fail in syncs, without > the command line or GTK UI talking to it at all.
I've implemented the shutdown/restart feature in the syncevo-dbus-server itself, as outlined by me above. I implemented a slight delay of 10 seconds before the the server shuts down or restarts. Making that delay too small would risk restarting while package upgrades involving the required files is still in progress. In the best case, it'll just restart again (likely for long running system updates?). In the worst case, it will fail to restart (system inconsistent) which then prevents further automatic syncs. Making it too large means that the server is blocked for a long time because new sync sessions are prevented right away. I hope I have covered all corner cases, like file updates happening while a sync session is currently active. I also wrote some tests, including these corner cases. I'd appreciate if someone could try out this code - David? For tracking I created a bug entry: https://bugs.meego.com/show_bug.cgi?id=14955 commit 23464d616a1a6584ea433e64f62b130cfd33205d Author: Patrick Ohly <patrick.o...@intel.com> Date: Mon Mar 28 13:52:28 2011 +0200 syncevo-dbus-server: shut down after on-disk changes are observed (BMC #14955) syncevo-dbus-server must restart after its installation was updated or removed. Otherwise further sync attempts can fail. This was seen in practice when SyncEvolution 1.0 was updated to 1.1 (Debian bug #617320): the in-memory daemon used an old libsynthesis, but the on-disk XML files required more recent libsynthesis features. In general, *any* update of something loaded into memory should trigger a shutdown or restart. A shutdown alone is okay when no automatic sync scheduling is needed (auto sync off for all configs). Clients will restart the daemon on demand. A restart is needed otherwise because without it, automatic syncs would stop to run. This patch implements the shutdown part. Restart still needs to be implemented. A 10 second delay is chosen between "file modified" and "shut down". This is meant to ensure that a future restart does not occur too soon (before all file changes are done). It's still a bit racy, but a better solution would depend integration into distro-specific hooks ("package update complete"), which is hard or impossible (installation via "make install" or "tar xf"). This new feature is tested by test-dbus.py, including several corner cases: - testShutdown: files modified in regular intervals for a while - testSession: a running session prevents the shutdown - testSession2: same as testSession, with different timing commit ec6eb438b32fdcbca665f4599355eab95d8644f0 Author: Patrick Ohly <patrick.o...@intel.com> Date: Mon Mar 28 15:43:33 2011 +0200 syncevo-dbus-server: restart when auto sync is enabled (BMC #14955) This patch also covers the case that the server needs to restart because it has to run automatic syncs. The restart is implemented as a brute-force execve() after removing output redirection, using the original argv and env arrays (Restart class). -- 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 SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
