On Mon, Dec 5, 2011 at 2:49 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mon, 2011-12-05 at 12:12 +0100, Chris Kühl wrote:
> On Wed, Nov 16, 2011 at 12:22 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > * logging:
> > * the main syncevo-dbus-server process should use syslog
> > logging for its own messages, without redirecting
> > stdout/stderr
> > * the forked process should start redirecting
> > stdout/stderr into the normal logging mechanism (so that
> > library error messages are visible when running the
> > syncevolution command line as client of the D-Bus server
> > and, later, they appear in log files) and switch to a
> > session log when the session is ready
> I plan to do this work in 3 steps:
> 1) The first step, which I've started, is to decouple the session and
> server from each other and also modify objects that require both the
> session and server objects as needed. Once this is done the server
> should function as it does now and all tests should pass in order to
> move on to step 2.
> 2) Move session into separate binary using a one-to-one dbus
> connection for communicating between the 2 processes. At this stage
> only one session is run at a time and all tests should pass as before.
One more question: what effect should SIGINT and/or SIGTERM have on the
I think both should be treated as an urgent request to shut down
operation. If a sync is running, it should be aborted and only after
that has worked should the main syncevo-dbus-server process quit.
Yes, cleanly exiting the running sync sessions before the server exits
I'll also be handling SIGCHILD in the server to make sure the server
can log a sync session ending unexpectedly and do any cleanup that's
return code should be 0 in all cases, to distinguish from errors
force the daemon to quit.
This is slightly different from the current behavior where SIGINT
requests a suspend and, if repeated quickly, only then forces an abort.
Users should never have relied on that behavior in the
syncevo-dbus-server and preserving it is simply not worth the extra
It should only be preserved in the command line tool, where the user
also gets immediate feedback on the first CTRL-C ("suspend requested,
CTRL-C again to abort").