On Tue, 2018-10-30 at 08:36 +0100, Milan Crha via evolution-list wrote: > On Mon, 2018-10-29 at 21:47 +0000, Patrick O'Callaghan wrote: > I even considered filing an RFE about it, suggesting there should bean option > to just force-close an account without waiting (I don'tremember if I ever got > round to it). > Hi,I do not recall seeing anything like that. I suppose you didn't see > itfor some time now, did you? You can force disconnect by usingFile->Work > offline, and once it's fully offline (the plug at thebottom-left part, in the > status bar, is unplagged and no otheroperations are showing in the status bar) > use File->Work Online toreconnect all the accounts. Whether it'll have the > same effect asquitting Evolution and starting it again I do not know. > Moreinteresting would be to know the reason for the slowness. Would therebe > any memory leaks involved? Who knows. > In any case, the UI itself is not supposed to be locked, all thenetwork > operations are ran in their own threads, not in the main/UIthread, thus for > example the window repaints when other window is movedabove it. > Many (8-10+) accounts can cause some sort of starving, caused by glib: > https://gitlab.gnome.org/GNOME/glib/issues/1223Evolution cannot do anything > with it, even it uses its own facilitieson few places to have GTask free of > some operations. > To John: how many accounts are we talking about, please? I used to haveenabled > 7 IMAPx accounts at once, I've only 4 currently, plus one POP,and I do not see > this issue, even in 3.26/3.28. If your UI is alsofrozen (the Evolution window > doesn't repaint, menu cannot be clicked,...), then it might be a different > thing. If it paints and there is no"close" button on the send/receive popup > window, then just right-clickits title bar and pick Close. Some desktop > environments have the closebutton hidden for some reason. As had been said in > other message inthis thread, there is no need to watch the window, it can be > closed,while the update itself will continue in the background. > The idea of concurrent connections is also valid, some servers do notlike it. > That's why the option is in the UI. > You can see what evolution does (where it is stuck) when you installdebuginfo > packages for evolution-data-server and evolution, then get itto that stuck > state and then get the backtrace of it. You can get thebacktrace with command > like this: $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` > &>bt.txtPlease check the bt.txt for any private information, like > passwords,email address, server addresses,... I usually search for "pass" > atleast (quotes for clarity only). > I suppose the evolution/IMAPx will be waiting for a response from theserver. > You can see what all of the IMAPx accounts do, the raw communicationsbetween > Evolution and the servers, when you run Evolution from aterminal like this: > $ CAMEL_DEBUG=imapx:io evolution > The output doesn't tell much to regular users, but you can at least seewhether > there's some progress/communication being done or not. As it'sfrom all enabled > IMAPx accounts it's easy to overlook whether all ofthe accounts are doing > something or not. You can use Send/Receive forrespective accounts only, if > it'll make any difference. > Bye, Milan > _______________________________________________evolution-list mailing > listevolution-list@gnome.orgTo change your list options or unsubscribe, visit > ...https://mail.gnome.org/mailman/listinfo/evolution-list Thank you for your help. I have isolated problem to one IMPAX account. Said account works fine in Outlook 365, but not in Evolution. Right now, Evolution is running two IMAPX.
john
_______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
