OS X Mojave, etesync-dav process not responding

[embamba]

On OS X Mojave 10.14.6, I've noticed in the Activities Monitor, one of the two etesync-dav processes displays as "Not Responding" with its line in red typeface. It's always the item with the app icon next to the process name, never the other process. Sometimes, it takes on this status within seconds after it launches. Other times, it takes longer. But it seems that after some period of time, it always gets there.

That said, I see no evidence that the process is actually hanging. Syncing works. Still, once the Activity Monitor identifies the process as not responding, it stays that way, even if it's working fine. Other processes, on occasion, go to not responding, then, after a few seconds or minutes, return to normal status.

In a browser window, https://localhost:37358 sometimes reroutes to localhost:37359. Other times, it fails, not necessarily when the process is not responding.

Syncing is successful in Thunderbird's TbSync addon. But I sometimes get a non fatal error (409) in the address book that I'm syncing. The error part of the log reads:

[tasn]

Thanks for reporting! Your message is cut after "the error part of the log reads:", could you please add the missing part?
From your description I believe we probably need to send a sort of a "ping" to activity monitor to let it know we are responding which we are not doing at the moment.
I'm a bit concerned about the reroute from 37358 to 37359 not always working, but it could just be that when you are testing it's a bit overloaded. Because etesync-dav is only intended to serve one user, it's number of worker threads is not very high.

[embamba]

Thanks for noticing the missing log data. Strangely, it disappears when I post it. If I edit the post, it reappears in the edit text box! Must be something about the XML chevrons. I had to remove the <> from each of the three lines to get it to appear.

error xmlns="DAV:"
valid-sync-token /
/error

[zakkak]

@embamba you can wrap the code in backquotes to make it appear properly.

e.g.

```
<error xmlns="DAV:">
<valid-sync-token />
</error>
```

will appear as

<error xmlns="DAV:">
<valid-sync-token />
</error>

[tasn]

Thanks @zakkak for weighing in!

@embamba: as we said, it works, right? It's just the activity monitor that shows it as not responding, right?

[zakkak]

In my case when it is not responding Calendar fails to sync. I never tried leaving it long enough to see if it ever revives, I usually kill the process and restart.

[tasn]

Does it actually happen to you often? I wonder if the Mac actively stops it because we don't do whatever they want us to do regarding "pings".

[zakkak]

I think once every couple of days. I will try to monitor it from now on.

[zakkak]

Right now I see it not responding but my contacts and the calendar are syncing fine

[embamba]

Thanks @zakkak for weighing in!

@embamba: as we said, it works, right? It's just the activity monitor that shows it as not responding, right?

Yes, it appears to work fine. Calendars and contacts have been syncing, the latter much better with this just released version 0.11.0 of etesync-dav.

[embamba]

Right now I see it not responding but my contacts and the calendar are syncing fine

This is exactly what I've been seeing. No syncing problems, even in this state in the Activity Monitor.

[tasn]

Thanks for the information!

@embamba: yeah, Contacts should now work! Let me know (in another ticket, possibly #70 if it's no longer the case).

[lasscap]

I had the same problem but everything worked fine with 0.9.1. Now I have updated to 0.11.0 and Activity Monitor shows me two entries/programs running for etesync. And one sometimes has ridiculously high CPU usage.

[tasn]

The CPU usage is probably because it's performing a large sync. Could you maybe run it with -D to see if there are any obvious error messages? Is the CPU usage momentary? If so, I wouldn't worry about it.

[lasscap]

Yes, you are correct :)

[tasn]

About which part? It's just a momentary large sync?
This is going to significantly improve in the future btw, but it should already be quite good, momentary and rare as it is. :)

[lasscap]

Yeah, that it is a momentary large sync. But I am still surprised because it is quite a large consumption of recourses.

[tasn]

It needs to decrypt all of your data which could be quite a bit, especially since at the moment it's done in Python if memory serves, rather than a faster implementation.