similar to: mremap_anon() failed: Not enough space

On 19 Jun 2019, at 13:13, Dave McGuire via dovecot <dovecot at dovecot.org> wrote: > Jun 19 14:47:31 <hostname> dovecot: [ID 583609 local0.error] > imap(<address>): Error: > mremap_anon(/var/mail/<domain>/<uname>/mailboxes/INBOX/Trash/dbox-Mails/dovecot.index.cache, > 255557632) failed: Not enough space > > I'm running 2.2.36.1 under Solaris 10

On 6/20/19 6:07 AM, @lbutlr via dovecot wrote: >> Jun 19 14:47:31 <hostname> dovecot: [ID 583609 local0.error] >> imap(<address>): Error: >> mremap_anon(/var/mail/<domain>/<uname>/mailboxes/INBOX/Trash/dbox-Mails/dovecot.index.cache, >> 255557632) failed: Not enough space >> >> I'm running 2.2.36.1 under Solaris 10 (patched to

Hey folks. Suddenly I'm getting lots and lots of messages like this in my logs: Jun 19 14:47:31 <hostname> dovecot: [ID 583609 local0.error] imap(<address>): Error: mremap_anon(/var/mail/<domain>/<uname>/mailboxes/INBOX/Trash/dbox-Mails/dovecot.index.cache, 255557632) failed: Not enough space I'm running 2.2.36.1 under Solaris 10 (patched to current) on

We're running dovecot 2.2.15 with pigeonhole 0.4.6, in a clustered environment, nfs with proxy and backend on all servers. I've been seeing some odd errors from lmtp: Error: mremap_anon(127930368) failed: Cannot allocate memory It seems to affect specific users, but it doesn't seem to manifest in any particular way; no user complaints. Just the occasional log message. I would

On 12/08/2014 02:54 AM, Andy Dills wrote: > > We're running dovecot 2.2.15 with pigeonhole 0.4.6, in a clustered > environment, nfs with proxy and backend on all servers. > > I've been seeing some odd errors from lmtp: > > Error: mremap_anon(127930368) failed: Cannot allocate memory > > It seems to affect specific users, but it doesn't seem to manifest

Pascal Volk writes: >> Cut&pasted off the terminal man page output. Looking into >> man1/doveadm-move.1, I see >> >> .B doveadm move \-u jane Archive/2011/09 mailbox INBOX BEFORE \(rs >> .B 2011-10-01 SINCE 01-Sep-2011 >> >> so it's a problem with my nroff, not dovecot's man pages. (Hmm, it >> happens with groff too -- it appears

> I don't have problems building 2.2.27 on Solaris 10 > (using Sun Workshop compiler 5.11). ... and I don't have problems with Solaris10/gcc, but I don't have as many options as you do. Joseph Tam <jtam.home at gmail.com>

On Thu, 24 Nov 2016, Steve Litt wrote >> add the public part of the cert into your system's trusted CA store. > > Silly question, but how would you do that? You didn't say which OS you're running on (alpine runs on Windows as well), but I'll assume *nix. A previous poster showed you how to do it with a real certificate, and the steps are the same. However, the way I

Looking further into this segfault at settings-parser.c:setting_copy():1519 *dest_size = *src_size; *src_size points to type size_t (typedef unsigned long), a 4-byte aligned value consistent with a 32-bit build. This is mismatched with declared type (gdb) whatis src_size type = const uoff_t * (gdb) whatis uoff_t type = unsigned long long (gdb) p sizeof(uoff_t) $1 = 8 resulting

Ah, okay, I see. submission_max_mail_size should be defined as uoff_t instead of size_t in struct submission_settings and struct submission_settings. > On 20 Jul 2019, at 1.47, Joseph Tam via dovecot <dovecot at dovecot.org> wrote: > > > Looking further into this segfault at > > settings-parser.c:setting_copy():1519 > *dest_size = *src_size; > > *src_size

Hopefully, there is some fix for issue 3 which is beyond my skill to fix. Issue 1) Need recent gcc version Building Dovecot versions <=2.2.x using gcc 3.4.4 worked, but this gcc version fails to build 2.3.x properly: symptoms include compile failures and executable crashes that depended on the amount of optimization used, which is usually a sign of compiler bugs. (It could also be

On Mon, 4 Dec 2017 12:53:15 -0800 (PST) Joseph Tam <jtam.home at gmail.com> wrote: > "Davide Marchi" <danjde at msw.it> writes: > > >> UW-IMAP's mailutil, imapsync, YippieMove and Larch. > > Whatever you use, *don't* use UW-IMAP's mailutil unless you got lots > of time to kill. It is dreadfully slow -- I used it to export some of >

On 04/12/17 23:15, Steve Litt wrote: > On Mon, 4 Dec 2017 12:53:15 -0800 (PST) > Joseph Tam <jtam.home at gmail.com> wrote: > >> "Davide Marchi" <danjde at msw.it> writes: >> >>>> UW-IMAP's mailutil, imapsync, YippieMove and Larch. >> >> Whatever you use, *don't* use UW-IMAP's mailutil unless you got lots >> of

A mail user reported that he filled up his INBOX (despite reminders he was approaching his filesystem quota), and furthermore, he could not fix the situation because he couldn't expunge message he marked for deletion. The dovecot logs revealed the cause dovecot: imap(user): Error: open(/var/mail/user.lock) failed: Disc quota exceeded This created an impasse where a user cannot free

We uograded our dovecot from version 2.1.10 -> 2.10.12, but within the first hour of use, dovecot-lda would segfault during delivery. This left a lock file lying around causing the user's mail readers to hang; much hilarity ensues. All further deliveries to the same user will result in a crash. The only thing that fixes this condition is to blow away the user's INBOX cache index.

On 12/08/2014 03:07, Teemu Huovila wrote: > A config would always be useful, but I can venture a guess. Perhaps the > affected users have a dovecot.index.cache file > somehwere, e.g. under INBOX, that is larger than the memory limit for > the lmtp process. Try increasing "default_vsz_limit" or > the "service lmtp { vsz_limit }". Removing the overly large index

> On 18 Oct 2015, at 20:25, Timo Sirainen <tss at iki.fi> wrote: > > On 18 Oct 2015, at 05:20, Joseph Tam <jtam.home at gmail.com> wrote: >> >> >> After setting imap_hibernate_timeout to 60s, I could not find any >> hibernated connections after a few hours. I tested hibernation and made >> an observation: IDLE'd imap sessions only

Thanks Joseph, Aki, but something missing from upgrade document, where does the dh param file go? I located ssl-parameters.dat so I will put it there. Quoting Joseph Tam <jtam.home at gmail.com>: > On Fri, 22 Jun 2018, Joseph Tam wrote: > >> However, recent advances make this condition obsolete [*] and not >> really safer, so a much faster way to generate a DH key is

Steve Litt asks > * And most important, where can I find the best, most unambiguous > Alpine documentation, that doesn't assume I know anything about > Alpine? The ~/.pinerc config file is well documented. There is a bewildering number of options, and you can tweak it just about anyway you like. Choice of mail readers tend to a religious issue. Users of a particular reader will

On Mon, 23 Sep 2019, Dave McGuire wrote: > On 9/23/19 8:36 PM, Steve Litt via dovecot wrote: >> Alpine appears not to be ready for prime time to act as a window into >> IMAP. > > Wha...? Alpine/Pine have implemented IMAP for decades; that was one > of the first IMAP implementations to see widespread use. Not surprising, as both the RFC for IMAP and Pine are creations of