Ralf Hildebrandt put forth on 11/8/2010 7:45 AM:
> * Kammen van, Marco, Springer SBM NL :
>
>> 6.9. The file-max parameter
>
> This doesn't override the ulimit for the user starting postfix.
> But of course it needs to be increased as well, this is true.
Increased to what? On my low RAM Lenny b
* Kammen van, Marco, Springer SBM NL :
> 6.9. The file-max parameter
This doesn't override the ulimit for the user starting postfix.
But of course it needs to be increased as well, this is true.
--
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité - Universitätsmedizin Berli
* Frank Bonnet :
>
> It depend on which Linux's version you use it seems
>
> I had this problem with Debian
So do I
> I've added the ulimit command INSIDE the script that launch
> Postfix to avoid the problem
This feels like cheating. For now I added it to /etc/default/postfix :)
--
Ralf H
lawlessliy, but how can I set the OS limits
"automagically"?
I already edited /etc/security/limits.conf to contain:
* hardnofile 8192
* softnofile 8192
but that results in the aforementioned "fatal: socket: Too many open
files" error.
>-Original Message-
>From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org]
>On Behalf Of Ralf Hildebrandt
>Sent: Monday, November 08, 2010 1:16 PM
>To: postfix-users@postfix.org
>Subject: fatal: socket: Too many open files
>Using
ementioned "fatal: socket: Too many open
files" error.
Postfix is running on kernel 2.6.x, Debian/GNU Linux.
--
Ralf Hildebrandt
Geschäftsbereich IT | Abteilung Netzwerk
Charité - Universitätsmedizin Berlin
Campus Benjamin Franklin
Hindenburgdamm 30 | D-12203 Berlin
Tel. +49
On 09/24/2010 04:56 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>>> Even then, a 1000 recipient list should be spread across two local(8)
>>> processes, each delivering transactions of 50 recipients side by side.
>>> I don't see that happen, so I suspect the measurement is inconclusive.
>>
Alexander 'Leo' Bergolth:
> > Even then, a 1000 recipient list should be spread across two local(8)
> > processes, each delivering transactions of 50 recipients side by side.
> > I don't see that happen, so I suspect the measurement is inconclusive.
>
> Unfortunately it doesn't. :-(
Actually, mul
On 09/24/2010 03:44 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> On 09/24/2010 02:31 PM, Wietse Venema wrote:
>>> Alexander 'Leo' Bergolth:
> Have you already tried the "no RESET_OWNER_ATTR()" solution?
I did a test run with the following aliases:
testlist: me
Alexander 'Leo' Bergolth:
> On 09/24/2010 02:31 PM, Wietse Venema wrote:
> > Alexander 'Leo' Bergolth:
> >>> Have you already tried the "no RESET_OWNER_ATTR()" solution?
> >>
> >> I did a test run with the following aliases:
> >>
> >> testlist: member1, member2, leo2
> >> owner-testlist: ro
On 09/24/2010 02:31 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>>> Have you already tried the "no RESET_OWNER_ATTR()" solution?
>>
>> I did a test run with the following aliases:
>>
>> testlist: member1, member2, leo2
>> owner-testlist: root
>> member1: leo
>> member2: tes
Alexander 'Leo' Bergolth:
> With one local(8) process, requeuing wouldn't make any difference, the
> been_here table would fill just as much as without an owner- alias.
That is incorrect.
With _destination_recipient_limit=1, there will be one recipient
per local(8) transaction. All local(8) state
On 09/24/2010 03:07 PM, Alexander 'Leo' Bergolth wrote:
> On 09/24/2010 02:31 PM, Wietse Venema wrote:
>> Alexander 'Leo' Bergolth:
Have you already tried the "no RESET_OWNER_ATTR()" solution?
>>>
>>> I did a test run with the following aliases:
>>>
>>> testlist: member1, member2, leo2
>>>
On 09/24/2010 02:31 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>>> Have you already tried the "no RESET_OWNER_ATTR()" solution?
>>
>> I did a test run with the following aliases:
>>
>> testlist: member1, member2, leo2
>> owner-testlist: root
>> member1: leo
>> member2: tes
Alexander 'Leo' Bergolth:
> > Have you already tried the "no RESET_OWNER_ATTR()" solution?
>
> I did a test run with the following aliases:
>
> testlist: member1, member2, leo2
> owner-testlist: root
> member1: leo
> member2: testleo
> # leo2 is a real user
>
> It requeues th
Wietse Venema:
> Wietse Venema:
> > Victor Duchovni:
> > > On Thu, Sep 23, 2010 at 07:26:59PM -0400, Wietse Venema wrote:
> > >
> > > > More sensibly, it seems safe to skip the RESET_OWNER_ATTR() operation.
> > > > That code is a remnant of a very early attempt to attribute bounces
> > > > very ac
On 09/24/2010 12:42 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> On 09/24/2010 01:26 AM, Wietse Venema wrote:
>>> Alexander 'Leo' Bergolth:
The other misfeature that I'd like to point out again is the behavior of
been_here() when the hash table is full.
>>>
>>> The alternatives
Alexander 'Leo' Bergolth:
> On 09/24/2010 01:26 AM, Wietse Venema wrote:
> > Alexander 'Leo' Bergolth:
> >> The other misfeature that I'd like to point out again is the behavior of
> >> been_here() when the hash table is full.
> >
> > The alternatives to a limited-size hash are a) run out of memor
On 09/24/2010 01:26 AM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> The other misfeature that I'd like to point out again is the behavior of
>> been_here() when the hash table is full.
>
> The alternatives to a limited-size hash are a) run out of memory and
> try to deliver mail repeatedly
Wietse Venema:
> Victor Duchovni:
> > On Thu, Sep 23, 2010 at 07:26:59PM -0400, Wietse Venema wrote:
> >
> > > More sensibly, it seems safe to skip the RESET_OWNER_ATTR() operation.
> > > That code is a remnant of a very early attempt to attribute bounces
> > > very accurately, and may be creating
Victor Duchovni:
> On Thu, Sep 23, 2010 at 07:26:59PM -0400, Wietse Venema wrote:
>
> > More sensibly, it seems safe to skip the RESET_OWNER_ATTR() operation.
> > That code is a remnant of a very early attempt to attribute bounces
> > very accurately, and may be creating more problems than it solv
On Thu, Sep 23, 2010 at 07:26:59PM -0400, Wietse Venema wrote:
> More sensibly, it seems safe to skip the RESET_OWNER_ATTR() operation.
> That code is a remnant of a very early attempt to attribute bounces
> very accurately, and may be creating more problems than it solves.
I think this idea has
Alexander 'Leo' Bergolth:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 09/23/2010 11:03 PM, Wietse Venema wrote:
> > Alexander 'Leo' Bergolth:
> >> OK, now I know why my messages are not requeued.
> >>
> >> First of all: The owner- alias IS REALLY set up correctly. :-)
> >>
> >> But if me
On 09/23/2010 11:03 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> OK, now I know why my messages are not requeued.
>>
>> First of all: The owner- alias IS REALLY set up correctly. :-)
>>
>> But if members of the list are aliases themselves, requeuing via cleanup
>> won't work for them. Un
Alexander 'Leo' Bergolth:
> OK, now I know why my messages are not requeued.
>
> First of all: The owner- alias IS REALLY set up correctly. :-)
>
> But if members of the list are aliases themselves, requeuing via cleanup
> won't work for them. Unfortunately, this is currently the case for my
> re
On 09/23/2010 03:48 PM, Victor Duchovni wrote:
> On Thu, Sep 23, 2010 at 03:36:27PM +0200, Alexander 'Leo' Bergolth wrote:
>> When the owner- alias IS configured correctly, HOW is delivery
>> distributed to multiple processes?
>
> See the deliver_indirect() code. A new message is put in the queue,
On Thu, Sep 23, 2010 at 03:36:27PM +0200, Alexander 'Leo' Bergolth wrote:
> On 09/23/2010 01:11 PM, Wietse Venema wrote:
> > Alexander 'Leo' Bergolth:
> >> However, I didn't notice any change such as separate processing of
> >> destination addresses.
> >>
> >> And I also cannot confirm that it use
Alexander 'Leo' Bergolth:
> On 09/23/2010 01:11 PM, Wietse Venema wrote:
> > Alexander 'Leo' Bergolth:
> >> However, I didn't notice any change such as separate processing of
> >> destination addresses.
> >>
> >> And I also cannot confirm that it uses a new queue id for each
> >> recipient. At whic
On 09/23/2010 01:11 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> However, I didn't notice any change such as separate processing of
>> destination addresses.
>>
>> And I also cannot confirm that it uses a new queue id for each
>> recipient. At which stage should the split happen?
>
> Wh
Alexander 'Leo' Bergolth:
> However, I didn't notice any change such as separate processing of
> destination addresses.
>
> And I also cannot confirm that it uses a new queue id for each
> recipient. At which stage should the split happen?
When the owner- alias is configured correctly, Postfix cre
en?
Maybe it cannot create a new queue file on error because the filehandle
limit is already reached? The verbose log says that it cannot connect to
the bounce and the defer service:
---- 8< --------
warning: cannot open file /home/lhock/.forward: Too many open file
Alexander 'Leo' Bergolth:
> Ah! The problem seems to be the duplicate_filter_limit!
>
> I set it to 1 and now everything works fine!
For the last time, you really should use the proper owner- alias
when delivering mail to a list. Then, one local(8) process will
never attempt to deliver more t
On 09/22/2010 04:53 PM, Alexander 'Leo' Bergolth wrote:
> On 09/22/2010 01:22 AM, Wietse Venema wrote:
>> Alexander 'Leo' Bergolth:
>>> On 09/21/2010 10:57 PM, Wietse Venema wrote:
Alexander 'Leo' Bergolth:
> Since yesterday I am experiencing big problems when delivering mail to
> an a
> >>> Do you have the RIGHT owner-listname alias.
> I am using alias_maps:
>
> # postconf | grep ldap
> alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf,
> ldap:/etc/postfix/ldap-groups.cf
>
> My owner- address is defined in hash:/etc/aliases and my list address in
> ldap:/etc/po
On 09/22/2010 01:22 AM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> On 09/21/2010 10:57 PM, Wietse Venema wrote:
>>> Alexander 'Leo' Bergolth:
Since yesterday I am experiencing big problems when delivering mail to
an alias-list. (Yes, I have set up an owner-listname alias. :-))
>>
Alexander 'Leo' Bergolth:
> I can smoothly send mails directly to the users with the problematic
> .forward files. (Directly as opposed to sending via the list-address.)
It also behaves as expected when I include "wietse" (with /dev/null
and \wietse in my .forward file) in an alias, whether or not
On 09/22/2010 05:20 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> The file contains:
>> 8<
>> x...@gmail.com
>> \lhock
>
> Your loop does not reproduce.
I know. :(
I don't think that the .forward file or its format are causing the problems.
I
Alexander 'Leo' Bergolth:
> The file contains:
> 8<
> x...@gmail.com
> \lhock
Your loop does not reproduce.
With this in my own .forward file:
/dev/null
\wietse
Sending mail to wietse results in one copy to /dev/null
and one copy to the mailbox file, an
IFREG|0644,
st_size=40, ...}) = 0
16:23:50.887138 open("/home/lhock/.forward", O_RDONLY|O_LARGEFILE) = 1023
16:23:50.889588 lstat64("/home/lhock/.forward", {st_mode=S_IFREG|0644,
st_size=40, ...}) = 0
16:23:50.890142 open("/home/lhock/.forward", O_RDONLY|O_LARGEFILE) =
Alexander 'Leo' Bergolth:
> On 09/21/2010 10:57 PM, Wietse Venema wrote:
> > Alexander 'Leo' Bergolth:
> >> Since yesterday I am experiencing big problems when delivering mail to
> >> an alias-list. (Yes, I have set up an owner-listname alias. :-))
> >
> > Do you have the RIGHT owner-listname alia
ering mail to a list which is implemented as an
>> ldap-alias-list (currently 289 recipients), the local daemon delivers
>> most of the mails to local mailboxes but then fails to open some
>> .forward files with "Too many open files". (See below.) The mail is then
>>
d as an
> ldap-alias-list (currently 289 recipients), the local daemon delivers
> most of the mails to local mailboxes but then fails to open some
> .forward files with "Too many open files". (See below.) The mail is then
> re-queued and fails again at the next queue flush
mailboxes but then fails to open some
.forward files with "Too many open files". (See below.) The mail is then
re-queued and fails again at the next queue flush.
The number of open files is currently limited to 1024:
# cat /proc/$(pgrep master)/limits | grep "Max open files&
Mihai Mustea:
> On 12/24/2009 6:58 PM, Gabriel Craciun wrote:
> > ulimit?!
> >
> >
> > On Thu, 2009-12-24 at 18:29 +0200, Mihai Mustea wrote:
> >> file-handles
> >
>
> Hey,
>
> I found out that I was running out of free inodes. Can that be the
> problem? I cannot test these days because there's
On 12/24/2009 6:58 PM, Gabriel Craciun wrote:
ulimit?!
On Thu, 2009-12-24 at 18:29 +0200, Mihai Mustea wrote:
file-handles
Hey,
I found out that I was running out of free inodes. Can that be the
problem? I cannot test these days because there's not much email traffic.
Thank you.
--
Mi
On 12/24/2009 7:01 PM, Gabriel Craciun wrote:
or /proc/sys/fs/file-max
on my server
cat /proc/sys/fs/file-max 130863
and I never run out of file handles...yet!
n Thu, 2009-12-24 at 18:58 +0200, Gabriel Craciun wrote:
ulimit?!
On Thu, 2009-12-24 at 18:29 +0200, Mihai Mustea wrote:
file-h
On 12/24/2009 6:58 PM, Gabriel Craciun wrote:
ulimit?!
On Thu, 2009-12-24 at 18:29 +0200, Mihai Mustea wrote:
file-handles
The default_process_limit was 100 until a few minutes ago (tried a
smaller limit).
ulimit = unlimited
Thanks.
--
Mihai-Ciprian Mustea
Senior Network Administrato
or /proc/sys/fs/file-max
on my server
cat /proc/sys/fs/file-max 130863
and I never run out of file handles...yet!
n Thu, 2009-12-24 at 18:58 +0200, Gabriel Craciun wrote:
> ulimit?!
>
>
> On Thu, 2009-12-24 at 18:29 +0200, Mihai Mustea wrote:
> > file-handles
>
ulimit?!
On Thu, 2009-12-24 at 18:29 +0200, Mihai Mustea wrote:
> file-handles
We cannot guess.
> >>Dec 20 13:44:32 1 postfix/bounce[30997]: D94D6538A71: sender delay
> >>notification: 89B1D53E893
> >>Dec 20 13:44:32 1 postfix/qmgr[30887]: warning: 6B0FB154F0E: defer
> >>service failure
> >>Dec 20 13:44:32 1 postfix/qmgr[30
/qmgr[30887]: warning: 6B0FB154F0E: defer
service failure
Dec 20 13:44:32 1 postfix/qmgr[30887]: warning: connect #1 to
subsystem private/defer: Too many open files
I got some deferred messages in the queue (mails to yahoo). Can you
tell me where this error is originated?
This is really obvious.
rvice failure
Dec 20 13:44:32 1 postfix/qmgr[30887]: warning: connect #1 to
subsystem private/defer: Too many open files
I got some deferred messages in the queue (mails to yahoo). Can you
tell me where this error is originated?
This is really obvious. There are no more file-handles lef
:32 1 postfix/qmgr[30887]: warning: connect #1 to subsystem
private/defer: Too many open files
I got some deferred messages in the queue (mails to yahoo). Can you tell
me where this error is originated?
Thank you.
--
Mihai-Ciprian Mustea
]: fatal: socket: Too many open files
I try to change some sysctl values like kern.maxfiles,
kern.maxfilesperproc, kern.ipc.maxsockets and kern.ipc.somaxconn but I
still receive too many open file message.
Someone know what is wrong?
Some extra info:
OS: FreeBSD 6.0 (same problem on FB-6.3
On Thu, Sep 11, 2008 at 08:25:48AM -0400, Wietse Venema wrote:
> > I try to change some sysctl values like kern.maxfiles,
> > kern.maxfilesperproc, kern.ipc.maxsockets and kern.ipc.somaxconn but I
> > still receive too many open file message.
> See: http://www.postfix.org/TUNING_README.html#file_
stfix/qmgr[52291]: fatal: socket: Too many open files
That is a kernel error.
> I try to change some sysctl values like kern.maxfiles,
> kern.maxfilesperproc, kern.ipc.maxsockets and kern.ipc.somaxconn but I
> still receive too many open file message.
See: http://www.postfix.org/TUNING_READM
Hi all,
I have a little problem with Postfix. I have a Postfix server acting as
fallback_relay. This box have a big queue (between 1 and 10
mails). The box is under FreeBSD and all is ok except this message I see
in syslog:
postfix/qmgr[52291]: fatal: socket: Too many open files
I try
abase /etc/postfix/recipient-access/domains/domainXYZ.db:
Too many open files"
Somebody can tell how to avoid that.
Wow, what a maintenance nightmare!
Postfix needs to open a file descriptor for all those lookup tables you
have defined. An excerpt from the INSTALL file:
--
... the
/recipient-access/domains/domainXYZ.db:
Too many open files"
Somebody can tell how to avoid that.
Wow, what a maintenance nightmare!
Postfix needs to open a file descriptor for all those lookup
tables you have defined. An excerpt from the INSTALL file:
--
... the number of file descript
ss/domains/domainXYZ.db:
Too many open files"
Somebody can tell how to avoid that.
This is our "main.cf"
smtpd_restriction_classes =
access-domain1
access-domain2
...
access-domain1 = check_sender_access
hash:/etc/postfix/recipient-access/domai
60 matches
Mail list logo
