Menu

#70 Socket error on localhost (127.0.0.1:1144): timeout. F: Callback leave bad store

1.4.4
cannot-reproduce
nobody
None
unknown
5
2024-07-29
2023-01-13
averter
No

There are threads with the same name as this ticket, but I am using 1.4.4 (unlike the authors of the other threads) and so this should not be a duplicate.
I am trying to pull 361 messages from my inbox work account, using a davmail + emacs combination. My config file is as follows

IMAPAccount work
Host localhost
Port 1144
User myusername@work.com
# To store the password in an encrypted file use PassCmd instead of Pass
PassCmd "echo ${PASSWORD:-$(gpg2 --no-tty -qd ~/.authinfo.gpg | sed -n 's,^machine outlook.office365.com login myusername@work.com .*password \\([^ ]*\\).*,\\1,p')}"
AuthMechs LOGIN
SSLType None
PipelineDepth 1

IMAPStore work-remote
Account work

MaildirStore work-local
SubFolders Legacy
Path ~/Mail/myusername@work.com/
Inbox ~/Mail/myusername@work.com/Inbox/

Channel work
Far :work-remote:
Near :work-local:
# Exclude everything under the internal [Gmail] folder, except the interesting folders
Patterns * !Calendar !Contacts !Conversation\ History !Archiv* !Tasks !Journal !Drafts !Notes !Sent\ Items !Outbox !Junk\ Email !Deleted\ Items
Create Near
Expunge Both
Sync All
SyncState *

if I run mbsync -cV ~/.mbsyncrc work there is a consistent timeout socket error

Socket error on localhost (127.0.0.1:1144): timeout.
On the other hand with debug mbsync -cD ~/.mbsyncrc work I get what's in the attached log and it indicates a callback leave bad store towards the end. Thank you in advance for any help.

1 Attachments

Discussion

  • averter

    averter - 2023-01-13

    I've found that this is due to some massive emails that I had in my mailbox, specifically 19.4MB and 30.5MB. I'm happy to close this although I would like to know if there is any other solution rather than just deleting the emails? Thanks.

     
  • Oswald Buddenhagen

    with git master you should get better diagnostics, specifically whether the transfer just takes long (in which case isync would be buggy) or the connection/server gets stuck (in which case isync behaves just fine).

    or you just use wireshark to observe the connection from the outside.

     
  • Oswald Buddenhagen

    • status: open --> need-more-info
     
  • Oswald Buddenhagen

    • status: need-more-info --> cannot-reproduce
     
  • Oswald Buddenhagen

    no info forthcoming.

     

Log in to post a comment.

MongoDB Logo MongoDB