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.o...@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
syncevo-dbus-server?
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. The
return code should be 0 in all cases, to distinguish from errors which
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
complication.
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").
--
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
