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 no
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
mboxlist_c
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
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 n
On Wed, 24 Sep 2003, Rob Siemborski wrote:
> 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.
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
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 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
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 th
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".
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
#
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,
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?
>
> Als
...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. Th
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
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]
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 d
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, 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 i
--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 - b
--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 t
--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 mes
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(
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 a
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 admi
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:
> > 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() [
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, 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 SA_REST
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 thro
On Wed, 24 Sep 2003, Etienne Goyer wrote:
> 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 deadl
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, 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 wi
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
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 ab
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, 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
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 the
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 t
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 siz
[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,
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 *
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 rele
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...
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*
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 happens
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 th
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
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 hea
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 sill
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
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 usu
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 rea
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
implementati
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]
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
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
--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, you
--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
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 to
cooperate with cyrus
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 Per
61 matches
Mail list logo
