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
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 filesystem
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 handle
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_MAX ==
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,
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, 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
a
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
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 nothing
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 -r
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
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
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 ended
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
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
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 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 gets
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
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 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, 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
complaints
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 realy
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
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
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
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
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 NFSv4
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 be
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
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
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 directory
40 matches
Mail list logo
