Bug 4089 - when running via su|ssh, CM stalls for 60 seconds on each received message
Summary: when running via su|ssh, CM stalls for 60 seconds on each received message
Status: RESOLVED INVALID
Alias: None
Product: Claws Mail
Classification: Unclassified
Component: Plugins/Notification (show other bugs)
Version: 3.17.2
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2018-09-15 18:44 CEST by Pierre Fortin
Modified: 2018-10-26 11:16 CEST (History)
0 users

See Also:


Attachments
debug output (10.27 KB, text/plain)
2018-09-15 18:44 CEST, Pierre Fortin
no flags Details
--debug output of test message processing (14.86 KB, text/plain)
2018-09-16 04:47 CEST, Pierre Fortin
no flags Details
modified debug output (1.78 KB, text/plain)
2018-09-17 22:25 CEST, Pierre Fortin
no flags Details
debug output (1.80 KB, text/plain)
2018-09-17 22:34 CEST, Pierre Fortin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre Fortin 2018-09-15 18:44:31 CEST
Created attachment 1916 [details]
debug output

I run 2 instances of CM (only POP3), one on my primary Linux account and another via "su - userid2" (or "ssh userid2@localhost"). On the main instance, incoming messages are checked and all seems fine. On the 2nd instance, when mail arrives, I'm seeing long delays where CM is totally unresponsive.

Ran with --debug which confirms 60 second delay -- see comments in debug output. 

For this test, I started CM and waited until it began polling on its own.
Comment 1 Pierre Fortin 2018-09-16 04:47:07 CEST
Created attachment 1917 [details]
--debug output of test message processing

Patched CM instance 2 to add timestamps (except plugins).
This output shows 2 test messages arriving in different polls.  
The first was sent by mailx and the 2nd from CM instance 1.

Message from:
mailx: no delay in processing
CM: 60 second hang

The full contents of these 2 messages are included at the end of this file.
Comment 2 Paul 2018-09-16 11:45:54 CEST
as was already suggested on the mailing list, disable the notification plugin as it is libnotify that appears to be causing the delay.
Comment 3 Pierre Fortin 2018-09-17 22:25:55 CEST
Created attachment 1918 [details]
modified debug output

Continued testing.  Added various debug_print statements and discovered 60 second delay is really 35 seconds and 25 seconds.
Comment 4 Pierre Fortin 2018-09-17 22:34:44 CEST
Created attachment 1919 [details]
debug output

Correction:  80s = 25s + 25s + 10s
Comment 5 Pierre Fortin 2018-09-18 05:54:55 CEST
Found the 25+25+10 second delays; but I don't know how to fix these; yet...

The first 25 second delay occurs in notification_trayicon.c:662
  caps = notify_get_server_caps();
which is getting a GList and looking for "actions".

  Added notify_is_initted() test which returns TRUE just before that call.


The second 25 second delay occurs in notification_trayicon.c:739
  if(!notify_notification_show(popup.notification, &(popup.error))) {


The 10 second delay occurs in notification_trayicon.c:743
   g_object_unref(G_OBJECT(popup.notification));