Re: [Evolution] Cannot add an appointment to my calendar

[Milan Crha <mcrha redhat com>]

On Wed, 2016-06-01 at 06:49 -0400, Adam Tauno Williams wrote:
> I have also seen this occasionally - on CalDAV calendars.  I
> **suspect** it has something to do with Evolution thinking it is
> offline, or the calendar is unreachable, or something like
> that.  Once it believes that it seems to get stuck in that belief -
> but I cannot make it happen consistently enough for it to be
> reproducible.

        Hi,
it looks like the
https://bugzilla.gnome.org/show_bug.cgi?id=721712
is back (this is not a query to reopen it, it's only a reference to a
bug where this was supposed to be addressed, which dates back to
3.12.11, thus something which is included in 3.18.x). 

> Rather than reboot I exit Evolution an kill the evolution-calendar
> -factory-subprocess processes.  Start evolution and it is good to go,
> again.

Killing the evolution-calendar-factory is also fine, it will take with
itself the subprocesses too.

> I have NO IDEA why that would ever happen on the 'default' local
> calendar - which I believe is what the original poster is describing.

Yeah, it's quite unlikely to see it with the On This Computer/Personal
calendar. Maybe a bug after the first run there (just after
initialization of the calendar after the first run for that particular
used). I do not know. It's possible to run the evolution-calendar-
factory from a terminal to see what it and its subprocesses do, the
command can be:
   $ /usr/libexec/evolution-calendar-factory -w &>/tmp/ecf-log.txt
There is no need to kill the previous process first, the new one will
replace the currently running. It's better to re-start processes which
use it, though, which includes the evolution and the evolution-alarm-
notify. Just an idea for the debugging, but as the restart of the
processes help, then the factory run from the terminal will not
reproduce the issue, most likely, because it's the same as the process
restart. Replacing the real evolution-calendar-factory process with a
script which will call the original factory with redirected output to
some file is an option too. I sometimes use(-d) it myself, to let the
process run through the D-Bus machinery, as it should be.
        Bye,
        Milan