Hi,
I've got a problem report from a user of my cyrus-imapd rpms who tried
to create a mailbox like this:
localhost.localdomain cm 'user.g0l6Pw-'
syntax error: cannot deal with `' here
I tried it on RedHat 7.2 and it works, but it doesn't on RedHat 9. RH7.2
uses Perl 5.6.1 while RH 9 uses Perl
Ken Murchison wrote:
Why not just have the newsserver feed directly to Cyrus?
Things aren't what they used to be. Typical providers will offer their
clients NNRP access with NEWNEWS disabled (if they offer news at all),
there is no talk of feeding.
Trying to get suck
--On Tuesday, September 23, 2003 23:11:25 -0400 Rob Siemborski
[EMAIL PROTECTED] wrote:
All messages that hit a sieve-compiled LMTPd are processed by sieve even
if that processing is just hey, look, there isn't a sieve script for this
user... moving on...
Which is what I suspected; and part of
--On Tuesday, September 23, 2003 21:58:03 -0700 Chris Stromsoe
[EMAIL PROTECTED] wrote:
On Tue, 23 Sep 2003, Pat Lashley wrote:
Just because lmtp is linked to sieve is no reason to assume that they are
(or should be) functionally intertwined.
I never claimed that they should be. In fact, your
On Tuesday 23 September 2003 23:58, Simon Matter wrote:
Hi,
I've got a problem report from a user of my cyrus-imapd rpms who tried
to create a mailbox like this:
localhost.localdomain cm 'user.g0l6Pw-'
syntax error: cannot deal with `' here
I tried it on RedHat 7.2 and it works, but it
On Tue, 23 Sep 2003, Rob Siemborski wrote:
On Tue, 23 Sep 2003, Pat Lashley wrote:
Once again. The fact that that header is predictively inserted into
the disk file is immaterial. It is even arguably wrong. (Although
that argument is likely to fail in the face of the performance
hello,
using cyrus-imapd-2.2-1 beta, found that the error log:
perl: No worthy mechs found
However, I have no problem to login .
My server is running RH9 with SASL 2.1.15
Any helps?
[EMAIL PROTECTED]
Oooppss. Sorry, my mailbox went temporarily over quota and the delivery
of the original thread was deferred until after I had read and responded
to the followup. It looks like the locking mechanism is working
correctly here and the bug is really in the network timeout. (or in the
Sep 24 09:50:30 imp imap[2030]: executed
Sep 24 09:50:30 imp imapd[2030]: accepted connection
Sep 24 09:50:47 imp imapd[2030]: accepted connection
...
Sep 24 09:51:15 imp imapd[2030]: accepted connection
...
Sep 24 10:26:23 imp imapd[2030]: Fatal error: Virtual memory exhausted
That was then a
Joakim Ryden schrieb:
On Tuesday 23 September 2003 23:58, Simon Matter wrote:
Hi,
I tried it on RedHat 7.2 and it works, but it doesn't on RedHat 9. RH7.2
uses Perl 5.6.1 while RH 9 uses Perl 5.8.0.
Does anybody know what the problem could be?
You could try the usual RH LANG
Hello,
How I can check in log file who download with POP3 or IMAP all mail from
what IP ??
Is it possible to check ?
-- Bart
On Tue, 23 Sep 2003, Andrew Morgan wrote:
I think your patch would fix the problem where are lot of processes are
contending for a lock (by making them retry), but it wouldn't help if a
single process keeps the lock indefinately.
I agree. The whole act of retrying for a lock is pretty silly,
On Wed, 24 Sep 2003, Chris Stromsoe wrote:
Yeah, if we were to correct the fact that we forward messages with the
Return-path, we'd correct it by skipping the first line of the file when
we were writing it back to the MTA, not by writing the initial file
without the Return-path header.
On Wed, 24 Sep 2003, Pat Lashley wrote:
Forgetting about Return-path for the moment. At the minimum the X-Sieve
header should be available (and probably the received header, since the
message was received before it was processed by sieve).
I thought you said above that sieve runs before
Hi,
I don't have time this morning to have a look at your patch and
understand the issue, but it reminded me of another bug I found a few
months ago. It may or may not relate to the problem you are fixing. I
just think you might be interested in knowing. It's the timeout part of
your problem
Hi!
I periodically fetch mail from my ISP via fetchmail and sort it into my IMAP
box via sieve. For some reason (reiserfs is crap?) it sometimes happens that
cyrus needs to recover DB and it not available during this time - but
fetchmail/sieve keep on going their job, of course.
So, it
On Wed, 24 Sep 2003, Rob Siemborski wrote:
think about it. The kernel is responsible for waking processes up when
they are blocking on a lock and it becomes available. If this isn't
happening (causing the need to do locks in a nonblocking fashion) then
something is wrong with the *kernel*
On Wed, 24 Sep 2003, Henrique de Moraes Holschuh wrote:
Agreed, but if we are going to keep the blocking-on-lock behaviour (and I
know we are ;-)), we really, really should have a way to timeout and kill
the process if that lock does not release after a while.
Resilience IS necessary... As
On Wed, 24 Sep 2003, Rob Siemborski wrote:
On Wed, 24 Sep 2003, Henrique de Moraes Holschuh wrote:
Agreed, but if we are going to keep the blocking-on-lock behaviour (and I
know we are ;-)), we really, really should have a way to timeout and kill
the process if that lock does not release
I just wanted to add something to this discussion...
First of all, we see the problem in Tru64 as well. When we upgraded to the
2.2 series, we put in the locking patch that John described below. This has
helped us, but the locking problem has *not* gone away... in fact, it does
a better job of
[EMAIL PROTECTED] wrote:
Hi!
I periodically fetch mail from my ISP via fetchmail and sort it into my IMAP
box via sieve. For some reason (reiserfs is crap?) it sometimes happens that
cyrus needs to recover DB and it not available during this time - but
fetchmail/sieve keep on going their job,
On Wed, 24 Sep 2003, Scott Adkins wrote:
3) The problem was characterized as an mmap() problem on Tru64 because
our mailboxes.db file is about 27MB in size. However, we are seeing
the sizes jump to 30-32MB in size, and our mailboxes.db file is still
only about 27MB in size.
Florian Hars wrote:
Ken Murchison wrote:
Why not just have the newsserver feed directly to Cyrus?
Things aren't what they used to be. Typical providers will offer their
clients NNRP access with NEWNEWS disabled (if they offer news at all),
there is no talk of feeding.
Trying to get suck
What version of Cyrus are you using? We are using 2.2b1 here, and are
experiencing something similar with memory issues for IMAP. I brought up
the discussion a few weeks ago about it and it was characterized as some
kind of mmap() weirdness on our Tru64 platform, which I don't really think
is
On Wed, 24 Sep 2003, Scott Adkins wrote:
Also, when we find the specific imaps process that happens to have the
cyrus.header lock file opened for writing and has it locked, if we kill
it off, we find that the write lock goes to another imaps process or to
one of the LMTP processes and gets
On Wed, Sep 24, 2003 at 11:13:06AM -0300, Henrique de Moraes Holschuh wrote:
It is not a general solution when you hit glibc/kernel bugs, but I can
certainly live with it IF I manage to track down a version of glibc and
kernel that won't deadlock, that we can recommend. Either that, or allow
On Wed, Sep 24, 2003 at 10:48:39AM -0400, Scott Adkins wrote:
What version of Cyrus are you using?
CVS HEAD from yesterday, which is called 2.1.15.
We are using 2.2b1 here, and are
experiencing something similar with memory issues for IMAP. I brought up
the discussion a few weeks ago about
On Wed, Sep 24, 2003 at 10:58:46AM -0400, Rob Siemborski wrote:
On Wed, 24 Sep 2003, Scott Adkins wrote:
3) The problem was characterized as an mmap() problem on Tru64 because
our mailboxes.db file is about 27MB in size. However, we are seeing
the sizes jump to 30-32MB in
On Wed, 24 Sep 2003, Etienne Goyer wrote:
The obvious solution is to not use alarm() to interrupt blocking
syscall, but to use non-blocking call with select() instead. I
am not a very proficient C Unix programmer, so maybe this suggestion
make no sense. However, in the case of the bug with
Assuming you have the logging of POP and IMAP sessions turned on for
that user, yes... Though, if you're asking, you probably don't.
If you create a directory named [configdirectory]/log/[username], POP
and IMAP sessions will be logged in it.
Bartosz Jozwiak wrote:
Hello,
How I can check in
On Wed, 24 Sep 2003, Rob Siemborski wrote:
However, I have looked into this and to my surprise, Linux is indeed
restarting the system calls instead of returning with EINTR. However, the
answer here is to set up the alarm() handler with sigaction without
setting SA_RESTART, not to jump through
On Wed, Sep 24, 2003 at 11:27:46AM -0400, Rob Siemborski wrote:
However, I have looked into this and to my surprise, Linux is indeed
restarting the system calls instead of returning with EINTR. However, the
answer here is to set up the alarm() handler with sigaction without
setting
On Wed, Sep 24, 2003 at 12:57:37PM -0300, Henrique de Moraes Holschuh wrote:
I did check ALL the documentation already, and ALL of it says that sigalarm
MUST interrupt the syscall, and that it HAS to return EINTR. So, it is a
bug. So, it needs to be squashed, and people have to either patch
On Wed, 24 Sep 2003, Etienne Goyer wrote:
I'll work on fixing fud shortly (its using signal() and it should be
using sigaction()).
The included patch against 2.1.13 work for me.
This sort of thing won't work for file locking. I've just committed a
patch to fud that uses sigaction() [Which
Ken Murchison wrote:
Florian Hars wrote:
Ken Murchison wrote:
Why not just have the newsserver feed directly to Cyrus?
Things aren't what they used to be. Typical providers will offer their
clients NNRP access with NEWNEWS disabled (if they offer news at all),
there is no talk of feeding.
On Wed, 24 Sep 2003, Etienne Goyer wrote:
Something that works in Linux, sure. Something that works in broken Linux?
No. Fix the breakage in Linux, instead. That's our strenght, and I *will*
stick to it as a Debian maintainer.
While I agree with you on a technical level and admire your
Thanks. I'll test it by the end of the week, and report.
On Wed, Sep 24, 2003 at 01:18:12PM -0400, Rob Siemborski wrote:
On Wed, 24 Sep 2003, Etienne Goyer wrote:
I'll work on fixing fud shortly (its using signal() and it should be
using sigaction()).
The included patch against
On Wed, 24 Sep 2003, Etienne Goyer wrote:
On Wed, Sep 24, 2003 at 11:27:46AM -0400, Rob Siemborski wrote:
However, I have looked into this and to my surprise, Linux is indeed
restarting the system calls instead of returning with EINTR. However, the
answer here is to set up the alarm()
--On Wednesday, September 24, 2003 09:30:52 -0400 Rob Siemborski
[EMAIL PROTECTED] wrote:
On Wed, 24 Sep 2003, Pat Lashley wrote:
I thought you said above that sieve runs before the 200 result. So
arguably, the message hasn't been -completely- recieved by lmtp until
sieve is finished.
The
--On Wednesday, September 24, 2003 01:45:12 -0700 Chris Stromsoe
[EMAIL PROTECTED] wrote:
I'm fairly certain that rfc2821 allows the initial mta to remove the
return-path header if it exists, so it is not incorrect to send the entire
message file when re-injecting the message.
Allowing an MTA to
--On Wednesday, September 24, 2003 15:57:32 +0200 [EMAIL PROTECTED] wrote:
I periodically fetch mail from my ISP via fetchmail and sort it into my
IMAP box via sieve. For some reason (reiserfs is crap?) it sometimes
happens that cyrus needs to recover DB and it not available during this
time -
On Wed, Sep 24, 2003 at 02:20:50PM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 24 Sep 2003, Etienne Goyer wrote:
On Wed, Sep 24, 2003 at 11:27:46AM -0400, Rob Siemborski wrote:
However, I have looked into this and to my surprise, Linux is indeed
restarting the system calls instead
Hello,
I just got cyrdeliver working from the command line. When using it with getmail
(fetchmail-like program) I get the following error message:
msg #1/3 : len 1960 ... retrieved ... failed delivering message (command
/usr/sbin/cyrdeliver wojtek exited 65 ()), skipping
When using the
On Wed, 24 Sep 2003, John Wade wrote:
The patch I wrote still might help you since it would prevent an
individual user's problem from taking down the mail system. The user's
mailbox would remain inaccessible, but the lmtpd processes attempting
delivery would exit with errors and mail
Andy,
Its happen to me before... Don't think it can't... That's all I'm
saying...
-John
Andrew Morgan wrote:
On Wed, 24 Sep 2003, John C. Amodeo wrote:
...until your system runs out of available open files...
Then the real fun begins... :-)
-John
[EMAIL PROTECTED] tools]# cat
On Wed, 24 Sep 2003, John C. Amodeo wrote:
...until your system runs out of available open files...
Then the real fun begins... :-)
-John
[EMAIL PROTECTED] tools]# cat /proc/sys/fs/file-max
209708
I'm in a lot of trouble if I've got 209708 files open. :)
Andy
...until your system runs out of available open files...
Then the real fun begins... :-)
-John
Andrew Morgan wrote:
On Wed, 24 Sep 2003, John Wade wrote:
The patch I wrote still might help you since it would prevent an
individual user's problem from taking down the mail system. The
On Wed, 24 Sep 2003, Scott Adkins wrote:
When looking at what file the processes are all waiting to get a lock on,
it usually turns out to be the cyrus.header file and not the quota file.
Is this still the same bug described by Rob on bugzilla? Does it have to
be the quota file?
Also,
Well, that could definitely be a problem... Next time we see a lock problem
occur, I will look based on the information below to see if it is really a
lock problem on the quota file.
Thanks,
Scott
--On Wednesday, September 24, 2003 12:32 PM -0700 Andrew Morgan
[EMAIL PROTECTED] wrote:
On Wed,
Rob,
I've just ran into this problem again. This time I have the gdb backtrace
of both the lmtpd process trying to get the lock and the imap process
holding the lock. There is nothing new in the lmtpd backtrace. Here is
the imapd backtrace:
0x402ae3c4 in read () from /lib/libc.so.6
(gdb) bt
Ken Murchison wrote:
Florian Hars wrote:
Ken Murchison wrote:
Why not just have the newsserver feed directly to Cyrus?
Things aren't what they used to be. Typical providers will offer
their clients NNRP access with NEWNEWS disabled (if they offer news
at all), there is no talk of feeding.
On Wed, 24 Sep 2003, Andrew Morgan wrote:
/dev/urandom for its entropy source, rather than /dev/random?
I've already compiled cyrus-sasl to use /dev/urandom. I'm not sure where
else I can change that, assuming this is the problem.
If the IMAP process is trying to read for periods on the
On 24 Sep 2003, Andrew Morgan writes:
I've just ran into this problem again. This time I have the gdb
backtrace of both the lmtpd process trying to get the lock and the
imap process holding the lock. There is nothing new in the lmtpd
backtrace. Here is the imapd backtrace:
0x402ae3c4 in
On Wed, 24 Sep 2003, Jonathan Marsden wrote:
On 24 Sep 2003, Andrew Morgan writes:
I've just ran into this problem again. This time I have the gdb
backtrace of both the lmtpd process trying to get the lock and the
imap process holding the lock. There is nothing new in the lmtpd
On Wed, 24 Sep 2003, Andrew Morgan wrote:
So it doesn't have /dev/(u)random open. But it does have a user's message
open. And the connection is one of our dial-up hosts, so it seems like
that the user's modem connection got abruptly dropped.
[snip]
It looks like somewhere along the line the
Nils Vogels wrote:
Ken Murchison wrote:
Florian Hars wrote:
Ken Murchison wrote:
Why not just have the newsserver feed directly to Cyrus?
Things aren't what they used to be. Typical providers will offer
their clients NNRP access with NEWNEWS disabled (if they offer news
at all), there is
On Tue, 23 Sep 2003, Rob Siemborski wrote:
On Tue, 23 Sep 2003, Chris Stromsoe wrote:
If it was intended to be a generic headers to add to every message
interface, do you have any objection to broadening it into an array of
struct Header {}, with code to add arbitrary headers from
Christos,
I've patched your cyrus-imapd-2.2.1-BETA-autocreate-0.8.1.diff patch to
successfully patch a CVS checkout on branch cyrus-imapd-2_2 as of today.
I've changed the name and bumped the version to 0.8.2 to reflect the
required changes (only 2 or 3 lines where the prototype for
I've created a patch that replaces the UCD SNMP code with it's
corresponding Net-SNMP 5.0.x requirements. I tried to limit my changes to
adding --enable-ucd-snmp-compatibility, but Cyrus wouldn't compile
successfully when I did that. The current patch does compile successfully,
although I've
59 matches
Mail list logo
