On Mon, Dec 5, 2011 at 2:49 PM, Patrick Ohly <[email protected]> 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 <[email protected]>
>> 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.
Yes, cleanly exiting the running sync sessions before the server exits
is essential.
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
needed.
The
> return code should be 0 in all cases, to distinguish from errors which
> force the daemon to quit.
>
Ok.
> 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.
>
Ok.
> 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").
>
Ok, noted.
Cheers,
Chris
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
