Re: Does cyrus user need a shell?

> they don't need one for running the Cyrus stuff. I realise I answered a slightly different question than you asked: "one" being an account, when you were asking about the shell. But the same answer holds true: since nothing is run in the context of the user, they don't need a shell. g

Re: Does cyrus user need a shell?

> whether cyrus (or other user cyrus-imapd runs as) need a shell? We run multiple servers, with tens of thousands of users' mailboxes on each, and there are only a few user accounts on the servers. Those are the admins. So the answer is no, they don't need one for running the Cyrus stuff. There

Re: cyrus-imapd-2.5 build broken at 865199d -- needs -lrt

Hello Ellie, > It sounds like we'll need to add some detection to configure.ac for > working out when to link against librt. As I mentioned in a prior message, this seems to be a problem on RHES 6.3 (and earlier?), but the v7 line has a more up-to-date glibc which apparently doesn't need -lrt

Re: cyrus-imapd-2.5 build broken at 865199d -- needs -lrt

Hello Philipp, > how old a glibc are we talking about? The dependency of clock_* > on rt was removed some time ago [0]. This is an up-to-date Redhat Enterprose 6.8 system. While not exactly leading edge, it's a current system, in use by many. It currently ships with:

cyrus-imapd-2.5 build broken at 865199d -- needs -lrt

On the cyrus-imapd-2.5 branch (currently 3a53853) from https://github.com/cyrusimap/cyrus-imapd, this commit: 865199d imapd.c: imapoptions: implement idle timeout introduces the use of clock_gettime() in imap/imapd.c. That means it needs to be linked with -lrt, but that is not happening on my

Re: giving sync_client the ability to back off and retry locked mailboxes

On Wed, 22 Jun 2016 12:25:28 +1000 ellie timoney via Cyrus-devel wrote: D) Don't add the new sync_action_list. If any operation returns > IMAP_MAILBOX_LOCKED, just sync_log() that operation and continue, and > let the next run deal with it. I meant to comment

Re: 2.5.7 -> 2.5.7 initial replication fails - failed to parse?

> Presumably there's no harm with running 'reconstruct -R' on "everything"? Shouldn't be, since reconstruct is supposed to fix all problems, and I used it quite a bit after the upgrade. I actually did `reconstruct -rfGO' over everything, which took a while. The -O option is because

Re: 2.5.7 -> 2.5.7 initial replication fails - failed to parse?

> Can I safely remove all of '/sync./*' and start the replication again? - I had a bit of fun & games getting some 2.5.7 servers up (upgraded from 2.4), and ended up doing a few `reconstruct -rfGO' runs on them, and forcing replication before it settled down. I can't answer your other

Re: Problems with subscriptions & Thunderbird on 2.5.7

On Fri, 15 Apr 2016 11:17:23 +1000 Robert Mueller via Cyrus-devel wrote: > FYI a user of ours encountered this recently and we came to the > conclusion it's a Thunderbird bug. An edited conversion I had with Bron > is below. [...] Many thanks for your response

Re: Problems with subscriptions & Thunderbird on 2.5.7

Before I head off to read RFCs, and try to understand what Cyrus is doing and Thunderbird, and what is going wrong, I just wanted to ask if anyone already knows the answers. Specifically, using LIST-EXTENDED, should a mail client be able to determine which folders are subscribed to, and if so

Re: Build problem with library locations in 2.5.7

Hello Ellie, > If I'm reading it correctly, it only affects builds from source with > --prefix=/usr Ah, that could be the case, as that's what we're using. Many thanks for your response though. Although it is not an issue for us really as there's a simple solution (moving the libraries), I

Problems with subscriptions & Thunderbird on 2.5.7

We recently upgraded to Cyrus IMAP v2.5.7 (compiled from 0ca3a92) from 2.4.17, and are seeing some strange issues with Thunderbird. The theory from the person who is working on this is that 2.5.7 introduced LIST-EXTENDED, and instead of using the old LSUB to get the folder subscription list, it

Crashes in lmtpproxyd, and a patch

We have a bunch of servers in a murder, and I recently took a look in /var/lib/imap/cores and found core files for lmtpd/lmtpproxyd all over the place. These seem to be generated in waves, and can occur on the front end imap proxy servers, the incoming e-mail servers, and the mailbox servers