IIRC MySQL tries to use an UNIX socket instead of TCP for connecting to
the server when it sees the "localhost" string. If e.g. sendmail runs
chrooted, then it won't see the MySQL server's socket, therefore it
won't be able to connect.
Gabor
On Sun, Feb 03, 2013 at 11:50:46AM +, Charles Brads
On Mon, Nov 22, 2010 at 11:03:15AM +0100, Sébastien Michel wrote:
> Since strace doesn't help to see what mmap reads on SELECT, so I made a test
> on NFS server.
On Linux you should use blktrace. NFS is a non-POSIX filesystem, and it
may show quite different behavior compared to a POSIX filesyste
On Wed, Sep 22, 2010 at 04:10:15PM +1000, Bron Gondwana wrote:
> Now - BDB database SHOULD be upgradable. I want to find a BDB expert
> to help me with that - (a) detecting that an upgrade is necessary, and
> (b) doing the upgrade.
It was quite some time ago I last upgraded a Cyrus instance, but
On Fri, Mar 26, 2010 at 12:01:01PM -0400, Greg A. Woods wrote:
> on "return" paths, perhaps, but not exit() paths -- there is no leak on
> exit() :-)
The leak of course happens much before exit(). But memory profilers
report unfreed memory after the process exits, and there is definite
difference
On Thu, Mar 25, 2010 at 10:30:42AM -0400, Greg A. Woods wrote:
> indeed, and memory "frees" itself at exit time too, and calling free() a
> whole lot of times on a sure path to exit() is a pedantic waste of time
> and code (and thus maintenance).
OTOH properly releasing memory on exit paths makes
On Thu, Nov 12, 2009 at 11:55:25AM -0800, David Lang wrote:
> > Use SMTP to breech the unreliable link! It's safe, proven, and designed
> > for that very task!
>
> no, SMTP only works if you have network connectivity that is up most of the
> time. it will handle short outages, but it will not h
On Thu, Nov 05, 2009 at 04:20:12PM -0800, David R Bosso wrote:
>
> Both the tls_sessions cache and statuscache look like good candidates to
> move to tmpfs. I don't see an easy way to relocate them, am I missing it,
> or should this be a feature request?
mount -t tmpfs tmpfs /some/where
cp /va
On Thu, Oct 29, 2009 at 10:00:54AM -0700, Andrew Morgan wrote:
> I always thought that it uses the service name from cyrus.conf (the first
> column on a service definition), but now that I look at my own systems I
> see that I am missing the /etc/pam.d/imaps file as well. Go figure!
... and if
On Mon, Jul 13, 2009 at 02:09:40PM +0200, Sebastian Hagedorn wrote:
> >4 GB limit of 32 bit binaries?
>
> Perhaps, although I haven't seen it.
That's only 3GB by default, 1GB of address space is reserved for the
kernel. Also, the stack, the executable, and all the shared libraries
the executable
On Fri, Jun 19, 2009 at 10:09:16AM +1000, Bron Gondwana wrote:
> @@ -192,6 +192,18 @@ struct db_list {
> static time_t global_recovery = 0;
> static struct db_list *open_db = NULL;
>
> +#define BIT32_MAX 4294967295U
> +
> +#if UINT_MAX == BIT32_MAX
> +typedef unsigned int bit32;
> +#elif ULONG
Hi,
I'm in the process of upgrading to 2.3.14 and looking at the gcc
warnings resulted in this change:
diff --git a/imap/lmtpengine.c b/imap/lmtpengine.c
index 3df2911..36d53bc 100644
--- a/imap/lmtpengine.c
+++ b/imap/lmtpengine.c
@@ -802,7 +802,7 @@ static int savemsg(struct clientdata *cd,
st
On Wed, Nov 12, 2008 at 02:48:35PM -0600, Mark Stover wrote:
> The IMAP spec doesn't mention a return order for items fetched, so I'm not
> sure if the return is something we can count on.
>From RFC3501:
sequence-set= (seq-number / seq-range) *("," sequence-set)
; set of
On Thu, Aug 07, 2008 at 10:51:21AM +0200, Paul van der Vlis wrote:
> make backups:
> cp -a /var/lib/cyrus /var/lib/cyrus-backup
> cp -a /var/spool/sieve /var/spool/sieve-backup
> cp -a /usr/lib/cyrus/ /usr/lib/cyrus-backup
> cp -a /var/spool/cyrus /var/spool/cyrus-backup
> The last one takes long.
On Thu, Aug 14, 2008 at 11:49:43AM +0200, Paul van der Vlis wrote:
> > Just a side note: I am pretty sure your mailboxes.db is a skiplist
> > database which is AFAIK the default for mailboxes.db in Cyrus IMAP 2.1
> > and 2.2. No conversion is necessary.
>
> I think that's correct, but I don't kno
On Thu, Apr 24, 2008 at 09:58:05AM +1000, Bron Gondwana wrote:
> Have you looked at:
>
> http://cyrus.brong.fastmail.fm/patches/cyrus-auditlog-2.3.11.diff
>
> It's a very detailed logging system which logs all create, delete,
> append, copy, expunge, unlink, etc events. Anything which changes
>
Hi,
Sorry I missed this e-mail in my INBOX...
On Tue, Mar 25, 2008 at 12:29:14PM -0700, Jo Rhett wrote:
> Gabor, it appears by light perusal that your patch would fix the
> original bug report for this problem: https://bugzilla.andrew.cmu.edu/
> show_bug.cgi?id=2894
Yes, it seems to be the s
On Fri, Mar 21, 2008 at 04:57:18PM +0100, Bart Coninckx wrote:
> Gabor, is this patch relevant when I do get a result onscreen from
> "reconstruct"?
Without the patch, "reconstruct -r" processes only the exact mailbox
given on the command line but does not descend into subfolders, like
when the "
On Fri, Mar 21, 2008 at 03:05:22PM +0100, Rudy Gevaert wrote:
> > su cyrus “/usr/lib/cyrus/bin/reconstruct –r user.testuser" the cyrus.*
> > files are not changed at all! I tried several things like logging in
> > with the cyrus user first and then issuing the command, or using "-rfx"
> > but n
On Thu, Feb 28, 2008 at 04:56:18PM -0600, Kenneth Marshall wrote:
> It may be that the software RAID 5 is your problem. Without the
> use of NVRAM for a cache, all of the writes need all 3 disks.
> That will cause quite a bottle-neck.
It's much worse than that. Since metadata updates are almost c
On Wed, Dec 05, 2007 at 11:34:10AM +, David Carter wrote:
> RFC 3501, section 6.3.5:
>
>Renaming INBOX is permitted, and has special behavior. It moves
>all messages in INBOX to a new mailbox with the given name,
>leaving INBOX empty. If the server implementation supports
>in
On Tue, Dec 04, 2007 at 10:06:23PM -0500, Wesley Craig wrote:
> The internal Cyrus "mailbox ID" ought to be unique, but it's not. On the
> sub folder, remove the cyrus.header file and reconstruct. This will assign
> a new, unique mailbox ID.
Thanks, that did the trick.
> Any ideal how they e
On Wed, Dec 05, 2007 at 08:48:00AM +, David Carter wrote:
> On Tue, 4 Dec 2007, Wesley Craig wrote:
> Changes to the Cyrus IMAP Server since 2.3.9
> [...]
>
> * Fixed the special case of RENAMEing an Inbox, so that it doesn't
> keep the same mailbox uniqueid, thus allowing it to
Hi,
I'm having problems with replication. sync_client bails out, and the log
contains:
Dec 5 02:00:50 mail cyrus/sync_client[6121]: RENAME received NO response:
Rename failed domain!user.foo -> domain!user.foo.bar: Operation is not
supported on mailbox
Why does sync_client want to rename the
On Tue, Nov 20, 2007 at 09:56:37AM -0800, David Lang wrote:
> for cyrus you should have the same sort of requirements that you would have
> for
> a database server, including the fact that without a battery-backed disk
> cache
> (or solid state drive) to handle your updates, you end up being t
On Fri, Nov 16, 2007 at 05:03:39PM -0800, Andrew Morgan wrote:
> I was able to get it to compile cleanly by adding "-fPIC" to the CFLAGS
> definition in each Makefile. I'm not sure if this is the correct solution
> though!
Yes, that's needed on x86_64 (at least until Cyrus starts providing
sha
On Fri, Nov 16, 2007 at 06:37:52PM +0100, Sebastian Hagedorn wrote:
> OK. Still the symptom seems to be different from what I'm seeing.
It may be. As I said I had no time so far to investigate it in depth, I
just wanted to say "mee too" for the hung process problem.
> Could it be that you have a
On Fri, Nov 16, 2007 at 11:17:23PM +0100, Sebastian Hagedorn wrote:
> I haven't yet found what BIO stands for According to Wikipedia it's "an
> abstraction library used by OpenSSL to handle communication of various
> kinds, including files and sockets, both secure and not".
You can think about
On Fri, Nov 16, 2007 at 06:11:01PM +0100, Sebastian Hagedorn wrote:
> Well, that just sounds like you're running out of entropy. That's a
> different issue. Recompile your cyrus-sasl to use /dev/urandom instead of
> /dev/random or disable apop in /etc/imapd.conf:
Debian uses /dev/urandom for a
On Fri, Nov 16, 2007 at 05:20:00PM +0100, Sebastian Hagedorn wrote:
> That's a 2.6 kernel, right?
Yes, 2.6.18-2-amd64.
> Hm, we don't suffer any actual slowdown, it's just that the number of
> processes increases over time.
It's not a slowdown - the client connects, and hangs. It never even ge
On Fri, Nov 16, 2007 at 12:36:49PM +0100, Sebastian Hagedorn wrote:
> He suggested that the trace is unreliable. Perhaps a bug in RHEL 3's
> version of OpenSSL messes up the stack. That would also explain why nobody
> else seems to have this problem.
FYI I also know a system that has problems w
On Thu, Nov 08, 2007 at 07:36:24PM +0100, Simon Matter wrote:
> It may not be worth for you to worry about it but it is worth for me and
> maybe also for Ken. People using my RPMs expect things to work. And people
> do use it on affected systems and they fill my mailbox or the list with
> complain
On Thu, Nov 08, 2007 at 06:39:45AM -0500, Ken Murchison wrote:
> That's friggin' great! We can't exactly force people to have a
> particular version of glibc just to run Cyrus 2.3.10. Either we need to
> come up with something that will run on all systems, or I'll be inclined
> to remove the
On Thu, Sep 13, 2007 at 02:32:51PM +0200, Frederic BRIAND wrote:
> There seems to be a trick to solve the problem, with an environment
> variable you must set, but I've not tested it. We moved to CentOS 5.
No, you can NOT solve the problem that way. You're just digging your
head in the sand prete
On Wed, Sep 12, 2007 at 08:10:29PM +0200, Alain Spineux wrote:
> When postfix try to deliver an email, it open a LMTP connection with cyrus
> and cyrus, instead of speaking correct LMTP reply with garbage.
> BUT 2c388000-2c479000 r-xp fd:00 12452057 /lib64/libdb-4.3.so
> is not re
On Fri, Jul 27, 2007 at 12:18:14PM -0400, Chaskiel M Grundman wrote:
> I asked the developers why the code was there, because on systems where
> "servername" points at an alias instead of a single name, the bind tends to
> fail and spams the syslog. These extra error messages confused debugging
Hi,
I'm in the process of upgrading from 2.3.7 to 2.3.8 and I noticed that
the sync_client from 2.3.8 can not connect to the replica. After some
head scratching I found that while sync_client from 2.3.8 uses the wrong
source IP address (the master host has several) when trying to connect
to the re
On Tue, May 22, 2007 at 11:14:49AM -0400, Robert Banz wrote:
> *security people seem to obsess on "perfect" solutions. It bothers me.
No, _real_ security people know that there is NO perfect solution. You
always have to balance the cost of the defenses with the cost of the
thing you want to prot
On Wed, Nov 29, 2006 at 09:36:55AM +0100, Simon Matter wrote:
> It has been tested but didn't work. See the posts from some days ago. It's
> either a configuration problem with the tests, an NFSv4 implementation
> problem with the tested Linux kernel, or something else.
AFAIK there is a known NFS
On Fri, Oct 06, 2006 at 11:24:00AM +0200, Simon Matter wrote:
> The groupfile patch implements a quick fix to the problem by using a separate
> group.cache file to speed up those operations using getgrent() calls.
> Calls to getgrnam() are not touched which means that the group.cache
> file must b
On Wed, Jul 12, 2006 at 05:02:10PM +0400, Дейтер Александр Валериевич wrote:
> Core was generated by
> `/home/devel/build/cyrus-imapd-2.3.7/imap/reconstruct -rf user.devel'.
> Program terminated with signal 10, Bus error.
> #0 0x000100011e04 in mailbox_write_index_header
> (mailbox=0x
On Mon, Apr 10, 2006 at 02:20:08PM +0200, Antoine Jacoutot wrote:
> Back to this thread again.
> So, after chatting with some OpenBSD devs, the included patch should fix the
> issue.
> It would be nice to officialy include it, if the fix is OK with you (and maybe
> with an #ifdef in case it only a
On Tue, Apr 04, 2006 at 08:29:45AM -0400, Ken Murchison wrote:
> Its entirely possible that the current code is taking advantage of a
> "feature" of Linux which is not intended to be exposed to the user.
>From 'man timezone':
The tzset() function initializes the tzname variable from the
Hi,
On Fri, Feb 10, 2006 at 01:00:25PM +0800, Murray Trainer wrote:
> The IMAP IDLE feature sounds like a good idea - do any mail clients
> support it yet.
The latest mutt version in Debian Sid has IMAP IDLE support. I did not
test it yet.
Gabor
--
---
On Mon, Nov 07, 2005 at 11:59:39AM +0100, Paul Dekkers wrote:
> >Make sure that you format ext3 partitions with dir_index which improves
> >large directory performance.
>
> ... but decreases read performance in general... at least that is what I
> found under RH / Fedora!
Yes, processing dire
44 matches
Mail list logo
