Expire doesn't seem to be removing messages

2015-10-13 Thread Tom Sparrow
I've tried this on the Kolab list and ServerFault with no result, so I'm 
hoping someone here can help.

I'm running a Kolab 3.4 server and Cyrus doesn't seem to be removing 
messages correctly. I've got full Trash directories on the filesystem 
from right back to when I brought the server into use (Feb), plus far to 
many messages in many other folders.

|/etc/imap.conf| has:

|deletedprefix: DELETED delete_mode: delayed expunge_mode: delayed |

|/etc/cyrus.conf| has:

|deleteprune cmd="cyr_expire -E 4 -D 69" at=0430 expungeprune 
cmd="cyr_expire -E 4 -X 69" at=0445 |

running cyr_expire manually with -D 30 removed some old mailboxes that 
hadn't hit 69 days yet, so that seems to be working. Running -X produces 
no results though, even with values less than the default 69:

Konsole output
/usr/lib/cyrus-imapd/cyr_expire -E 4 -X 30 -v -a
Expunging deleted messages in mailboxes older than 30.00 days

Expired 0 and expunged 0 out of 0 messages from 0 mailboxes


I was looking at the expiry values, and set a couple to 7 yesterday, but 
it hasn't made any difference. I found the -a option today on 
http://cyrusimap.web.cmu.edu/docs/cyrus-imapd/2.4.8/man/cyr_expire.8.php 
but since that makes no difference either I'm assuming the expire values 
are not the issue.

Any help gratefully received at this point, I'm pretty much out of ideas 
(short of deleting the files manually every now and then, which is not 
really a path I want to go down).

Thanks,
Tom.

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus


Re: 2.4.17 --> 2.5.3 Some mail folders no longer accessible

2015-10-16 Thread Tom Sparrow
Not sure how 'answered' this question is since 3rd, but since I was 
having this problem this week thought I'd pitch in.

I used
sudo -u cyrus /bin/sh
which saves on forgetting to change it back (and has the advantage of 
not opening anything up further than required in the mean time).


On 16/10/15 12:42, Sebastian Hagedorn wrote:
> --On 3. Oktober 2015 05:51:42 -0500 Patrick Goetz 
>  wrote:
>
>> I have a question about best practices.  I usually have the shell for
>> user cyrus set to /bin/false.  So to run a reconstruct, I have to change
>> this to /bin/bash (or something) first in order to be able to log in as
>> cyrus and execute the reconstruct command.
>>
>> On the other hand, this is only the second time I've had to run
>> reconstruct in 12 years of using cyrus.  What do most people do about
>> this?  Is cyrus an ordinary user who can log in by default, or is it
>> best practice to have shell /bin/false, as I do with most other daemon
>> users?
>
> We use user cyrus all the time. Not only for reconstruct, but also for 
> tools like mbexamine, chk_cyrus etc.
>
>
> 
> Cyrus Home Page: http://www.cyrusimap.org/
> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
> To Unsubscribe:
> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus