similar to: 2.2.0rc6: crash with mailbox_list_index=yes (and virtual?)

Displaying 14 results from an estimated 14 matches similar to: "2.2.0rc6: crash with mailbox_list_index=yes (and virtual?)"

2014 Apr 01
2
imap process and indexer-worker crash while creating folders
Hi, our dovecot processes sometimes crash when we create new folders. The "imap" process and the "indexer worker" process is crashing. We can reproduce this, we have a java program with multiple threads, and sometimes 2 threads try to create the same folder for the same user, and if both collide, dovecot processes crash. We don't see this happening in the real world if
2013 Aug 28
2
mailbox_list_index, stops showing new mails in mailboxes
Hello. I'm having some weird problem with (probably) mailbox_list_index, that it doesn't see new mail in mailboxes. I'm using 2.2.4 over imap and ssh/imap, and after a while dovecot stops noticing new mail in some folders. Its always the same 2-3 folders of about 30. I read something about list-index corruption in 2.2.2, and i thought it was that i was running into earlier, but this
2018 Feb 11
1
mailbox_list_index documentation?
I find mailbox_list_index on some doc pages, but not explaination to find what precisely it does? Would someone care to mind explain? Thank you! ------------------------------------------------- ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands! $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk
2018 Aug 14
0
Inbox quota usage doubled when mailbox_list_index enabled, under some circumstances
I?ve had the opportunity to test the same configuration with a fresh build of the git master branch (2.4.devel) and the issue also occurs there. I see that "mailbox_list_index = yes" is now enabled by default. It can still be disabled via "mailbox_list_index = no" which allows the quota to be calculated correctly. ========== root at ubuntu1804:~# dovecot -n # 2.4.devel
2015 Dec 05
1
mailbox_list_index and maildir_very_dirty_syncs are in conflicts?
Hi, I?m running Dovecot 2.2.19 with Maildir as storage and LDA for delivery. I noticed that if I set mailbox_list_index=yes and maildir_very_dirty_syncs=yes when I login via IMAP the STATUS command don?t ?see? new messages in sub-folders (like Spam). Example, a new message as arrived in Spam folder (I can see in Maildir/new/) but IMAP STATUS don?t see it: . STATUS Spam (MESSAGES UNSEEN) *
2018 Jul 26
3
Inbox quota usage doubled when mailbox_list_index enabled, under some circumstances
Hello, I searched through the list archives for anything that appeared to be similar to this but I didn't find any good matches.? I apologize if this has been brought up before. Beginning with Dovecot 2.2.34, reported quota usage of a user's inbox can be doubled when the following criteria are met: 1) quota plugin is enabled 2) mailbox_list_index=yes 3) A sub-folder of the inbox
2007 Oct 08
2
rsync error: protocol incompatibility (code 2) at main.c(1385)
Hello, i'm trying to backup one of my hosts with a two rsync-scripts, which are mainly just calling on the client side /usr/bin/rsync --server --sender -vlogDtprz --delete-excluded --numeric-ids --exclude-from=/etc/sm-backup/rsync.exclude / and on the server side rsync -avz --numeric-ids -e "ssh -i $key" --delete --delete-excluded rsync@$client:/ $DATA_PATH/$client/daily.0
2017 Jul 08
2
Error in v64i32 type in x86 backend
Thank you. i understood how avx512 vector instructions are written in x86instravx512. i need to define my vector instructions so i wrote; def VMOV_256B_RM : I<0x6F, MRMSrcMem, (outs VR2048:$dst), (ins i32mem:$src), "vmov_256B_rm\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (v64i32 (scalar_to_vector (loadi32 addr:$src))))],
2017 Jul 08
2
Error in v64i32 type in x86 backend
Thank you; i have changed as follows.is it fine now? def VADD_256B : I<0xFE, MRMDestReg, (outs VR2048:$dst), (ins VR2048:$src1, VR2048:$src2), "VADD_256B\t{$src, $dst|$dst, $src}", [(set VR2048:$dst, (add VR2048:$src1, VR2048:$src2))]]>; Also here i have changed class RI to I. Does it make any difference? On Sat, Jul 8, 2017 at 9:38 AM, Craig Topper
2006 Apr 18
1
inserting value got problem
Parameters: {"bestandsliste"=>{"typ"=>"bumffer", "KundanName"=>"parikshit", "Abgeholt"=>"", "LieferLand"=>"", "Kaufmann"=>"birla", "Marge"=>"", "Erzieltervk"=>"", "LieferOrt"=>"",
2017 Jul 08
5
Error in v64i32 type in x86 backend
Thank You. I have seen the opcode is 8 bits and all the combinations are already used in llvm x86. Now what to do? On Sat, Jul 8, 2017 at 10:57 AM, Craig Topper <craig.topper at gmail.com> wrote: > Yes its an opcode conflict. You'll have to look through Intel documents > and find an unused opcode. I've only added instructions based on a real > spec so I don't know
2012 Aug 01
7
[PATCH] Btrfs: barrier before waitqueue_active
We need an smb_mb() before waitqueue_active to avoid missing wakeups. Before Mitch was hitting a deadlock between the ordered flushers and the transaction commit because the ordered flushers were waiting for more refs and were never woken up, so those smp_mb()''s are the most important. Everything else I added for correctness sake and to avoid getting bitten by this again somewhere else.
2015 Mar 11
1
Not able to access CIFS share using samba
Hi, I am not able to access the local CIFS share using samba on unix machine. It is returning with Access Denied. Please see the attachment for more details. Thanks, Dhyan -------------- next part -------------- 03:09:50.311663 IP dev-130.odc.reconnex.net.ssh > 10.213.132.83.64001: P 339078270:339078322(52) ack 1209710857 win 9648 03:09:50.311694 IP dev-130.odc.reconnex.net.ssh >
2008 Jun 30
4
Rebuild of kernel 2.6.9-67.0.20.EL failure
Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking