The following issue has been RESOLVED.
==
http://www.dbmail.org/mantis/view.php?id=125
==
Reported By:aaron
Assigned To:paul
The following issue has been RESOLVED.
==
http://www.dbmail.org/mantis/view.php?id=309
==
Reported By:matija
Assigned To:paul
The following issue has been CONFIRMED.
==
http://www.dbmail.org/mantis/view.php?id=302
==
Reported By:idk
Assigned To:paul
The following issue has been CONFIRMED.
==
http://www.dbmail.org/mantis/view.php?id=301
==
Reported By:idk
Assigned To:
A NOTE has been added to this issue.
==
http://www.dbmail.org/mantis/view.php?id=299
==
Reported By:adamg
Assigned To:
This is a long-standing issue. If anyone has any ideas I'd be happy to
hear them.
Marc Dirix wrote:
I've installed dbmail from svn over the debian rules script,
The problem I think is, that one of the dbmail processes (lmtp or imap
I use both) doesn't completely detach from the console.
dbmail-dev rev 2013 doesn't work, it writes permission denied when I
trying to see messages list in any folder using squirrelmail or Thenderbird.
Add - - 2- and stuff your startup script.
But you should have already known to do that. init.d scripts are
unreliable and no decent unix administrator should recommend them for
running services.
Something as critical as email should probably be run from inittab (or
daemontools) anyway- unless
As always Geo, I'll take your recommendations to heart.
Geo Carncross wrote:
Add - - 2- and stuff your startup script.
But you should have already known to do that. init.d scripts are
unreliable and no decent unix administrator should recommend them for
running services.
Something as
and the sorts are sollutions to daemonize non daemons, not to
use them for actual ones.
That has nothing to do with the fact that a good daemon has means to
distantiate itself from the console it is started from.
I'm going to start a flame-ware, but IMHO every systemadmin has to
have the right
On Mon, 2006-03-06 at 17:19 +0100, Marc Dirix wrote:
and the sorts are sollutions to daemonize non daemons, not to
use them for actual ones.
Why?
The shell is already there. What does the additional complexity actually
bring?
That has nothing to do with the fact that a good daemon has
Geo Carncross wrote:
Daemons also run as root. Root-owned processes shouldn't be killed so
quickly by the OOM killer, so getting them killed by other means (say,
reasonable resource limits) is even more important.
The OOM Killer should be killed itself. I keep up with the PostgreSQL
lists
Hello
Paul J Stevens wrote:
This is a long-standing issue. If anyone has any ideas I'd be happy to
hear them.
perldoc -q daemon :
How do I fork a daemon process?
If by daemon process you mean one that's detached (disassociated from its
tty), then the following process is reported to work on
On Mon, 2006-03-06 at 13:26 -0500, Matthew T. O'Connor wrote:
Geo Carncross wrote:
Daemons also run as root. Root-owned processes shouldn't be killed so
quickly by the OOM killer, so getting them killed by other means (say,
reasonable resource limits) is even more important.
The OOM
Geo Carncross wrote:
On Mon, 2006-03-06 at 13:26 -0500, Matthew T. O'Connor wrote:
The OOM Killer should be killed itself. I keep up with the PostgreSQL
lists and they *HIGHLY* recommend disabling the OOM killer. The section
16.4.3 for details:
Igor Olemskoi wrote:
dbmail-dev rev 2013 doesn't work, it writes permission denied when I
trying to see messages list in any folder using squirrelmail or
Thenderbird.
It seems, that db_acl_has_right (in db.c) doesn't get mailbox-owner_idnr
LOG:
COMMAND: [11 SELECT INBOX/dbmail/my]
arg[0]:
On Mon, 2006-03-06 at 14:33 -0500, Matthew T. O'Connor wrote:
I disagree here, a program can intelligently deal with a malloc()
failure, PostgreSQL does this very well in fact. A program can not deal
intelligently with getting killed at random moments. So I disagree that
OOM is a way of
Oleg Lapshin wrote:
o Reopen STDIN, STDOUT, and STDERR so they're not connected to the old tty.
Heh! That must be it. Makes sense, and it's the only thing not being
done already.
Will try, thanks.
--
Paul Stevens
problem fixed, bug closed. calling freopen on the std streams does the
trick. Code extracted to new function in server.c,server_daemonize if
you want to see how it's done atm.
--
Paul Stevens
I think if you want to start the process in your special
way, you could make an option for dbmail to not daemonize, and
let the others use it like they are used to. There are a lott good
daemons who have an console switch to not fork and kill tty.
/Marc
Marc Dirix wrote:
I think if you want to start the process in your special
way, you could make an option for dbmail to not daemonize, and
let the others use it like they are used to. There are a lott good
daemons who have an console switch to not fork and kill tty.
As does dbmail.
Yep. That's me working on bug #125. Looks like your getting corruptions
where my tests pass without errors.
I'll track this down asap.
Oleg Lapshin wrote:
Igor Olemskoi wrote:
dbmail-dev rev 2013 doesn't work, it writes permission denied when I
trying to see messages list in any folder using
Let's see if I got the gist of this thread:
Fork detach: the intended the default (although broken in 2.1.4)
because most people expect it to work this way.
Fork no-detach: parents stays connected to the tty so that failures
are quickly detected by an appropriate wrapper script / init /
On Mon, 2006-03-06 at 23:06 +0100, Paul J Stevens wrote:
Marc Dirix wrote:
I think if you want to start the process in your special
way, you could make an option for dbmail to not daemonize, and
let the others use it like they are used to. There are a lott good
daemons who have an
Paul J Stevens wrote:
problem fixed, bug closed. calling freopen on the std streams does the
trick. Code extracted to new function in server.c,server_daemonize if
you want to see how it's done atm.
Let's see.
TRACE_STDERR 0
dbmail daemonizes
and ?
we have nothing on STDERR ;)
And:
Same error here!
And:
# make
.
db.c: In function `acl_query':
db.c:3751: error: `mailbox' undeclared (first use in this function)
db.c:3751: error: (Each undeclared identifier is reported only once
db.c:3751: error: for each function it appears in.)
db.c: At top level:
db.c:3748:
These are the commands that my Squirrelmail 1.4.5 server issues when
connecting to dbmail-2.1.5:
A001 LOGIN user password
A002 SELECT INBOX
A003 EXPUNGE
A004 EXAMINE INBOX
A005 SELECT INBOX
A006 EXPUNGE
A007 EXPUNGE
A008 UID SORT (ARRIVAL) ISO-8859-1 ALL
A008 takes quite a bit of time to
We've been having terrible load issues with 2.0.9 and only about 300
users. We've got dual 3.6ghz Xeons with 1M L2 cache and 4G of ram
and a RAID5 979G. During our heavy load hours (9-5) the system
crawls to the point of timing out many mail client operations. The
load averages are
To all,
What email clients does dbmail support for connecting thru IMAP or POP?
I use Evolution and Dovecot now.
Jim
Try PostgreSQL. Not to start a flame-war, but it's been my experience
that Postgres does better in highly concurrent environments like what
you have described.
Greg Hellings wrote:
We've been having terrible load issues with 2.0.9 and only about 300
users. We've got dual 3.6ghz Xeons with
Hi
select * from dbmail_users;
+---++--+-+--+--+--
16 | accounts | gsisac | 0 | 10485760 | 554
| | 2006-03-04 12:27:51 |
17 | ttt
Anything that's IMAP compatible, right? :)
I've used successfully:
Outlook
Evolution
Kmail
Squirrelmail (imap only)
Eudora
Thunderbird
Yahoo Mail (POP3)
GMail (POP3)
The POP client used in PalmOS 4.x (sorry, forgot the name)
Netscape
It's pretty universal, although a few problems have cropped
Thanks for the heads up. I'll be running into this issue as well since
I'm using CentOS in production. In any case, I did find a newer version
of glib2-devel over at:
http://mland98.rc.kyushu-u.ac.jp/pub/centos/4.2/mland/i386/
Haven't tried to install it myself yet
Best,
Adam
Dan
Greg Hellings wrote:
We've been having terrible load issues with 2.0.9 and only about 300
users. We've got dual 3.6ghz Xeons with 1M L2 cache and 4G of ram and a
RAID5 979G. During our heavy load hours (9-5) the system crawls to the
point of timing out many mail client operations. The
Micah Stevens wrote:
Anything that's IMAP compatible, right? :)
I've used successfully:
Outlook
Evolution
Kmail
Squirrelmail (imap only)
Eudora
Thunderbird
Yahoo Mail (POP3)
GMail (POP3)
The POP client used in PalmOS 4.x (sorry, forgot the name)
Netscape
add:
pine
mutt
sylpheed
You should consider setting up a ldap addressbook, if you want it
centraliyed for more users/computers.
Which is not in the dbmail scope.
/Marc
On Thu, Mar 02, 2006 at 10:35:33PM -, Jorge Bastos wrote:
Ok
Hehe, it was just a silly question, i just remembered of asking... :P
Jorge
Hi Greg:
I keep coming back to this message when I need to break from a project I am
working on so I'll let this fly now and see if it gets some ideas going for
you
( I see since I started this Mathew has dropped you a note about PostGreSQL
which is just so true. Sure some mysql folks
Thats what I thought about IMAP. Since installing dbmail I can't connect
from Evolution.
...this is my log file,
Mar 6 09:52:28 cpe-33-44-561-78 postfix/master[30240]: daemon started --
version 2.2.2, configuration /etc/postfix
Mar 6 09:52:32 cpe-33-44-561-78 postfix/smtpd[30244]: fatal:
Postfix has nothing to do with IMAP either. Looks like your SMTP setup is
hosed. Somewhere (I'd look at aliases, or virtual domains first) your config
files are setup to look in mysql for data instead of a file.
You could either tell it different, or install postfix-mysql.
On Monday 06
I took out this line out..
#local_recipient_maps = mysql:/etc/postfix/sql-recipients.cf
..and can now send from Evolution. So I guess you must compile Postfix with
mysql support for dbmail to work.
Jim
From: Micah Stevens [EMAIL PROTECTED]
Reply-To: DBMail mailinglist dbmail@dbmail.org
No you don't. Whether DBMail is there or not would not of affected your
solution, you were telling Postfix to look at a mysql table for it's SMTP
recipients list. This would be an issue with a non-mysql compiled Postfix
regardless of whether or not DBMail was there.
-Micah
On Monday 06
M. J. [Mike] OBrien wrote:
( I see since I started this Mathew has dropped you a note about
PostGreSQL which is just so true. Sure some mysql folks don't like
hearing that but if you know pgsql it's not so scary)
We picked mysql because we do want to replicate and cluster the database
Greg Hellings wrote:
The size of the users mail boxes is likely our biggest problem. A
previous manager refused to allow quotas, and now some users have mail
boxes up to 5 gigs. We are working on reducing it.
Be ware of clients doing client-side filtering:
0123 SELECT BiGbOx
0124 UID
Hi,
You say,
The size of the users mail boxes is likely our biggest problem. A
previous manager refused to allow quotas, and now some users have mail
boxes up to 5 gigs. We are working on reducing it.
Maby that's why is a previous manager
I say
Impose Quotas because on day your database
44 matches
Mail list logo
