Jos Chrispijn:
[ Charset windows-1252 converted... ]
> On 3-6-19 13:09, Wietse Venema wrote:
> > postmap hash:/postfix/tables/spamtrap what is this?
>
> # spamtrap 180711
> partmaps@?? DISCARD
>
> in main.cf
> check_recipient_access? hash:/postfix/tables/spamtrap,
>
> I adde
On 3-6-19 13:09, Wietse Venema wrote:
postmap hash:/postfix/tables/spamtrap what is this?
# spamtrap 180711
partmaps@ DISCARD
in main.cf
check_recipient_access hash:/postfix/tables/spamtrap,
I added this some time ago referring to
http://postfix.1071664.n5.nabble.com/N
Jos Chrispijn:
> Hi Jan,
>
> On 30-5-19 14:47, Jan Ceuleers wrote:
> > Jos, what I think everybody is trying to tell you is that your cron job
> > has swept the problem under the rug, for now, but that it is still there.
>
> Yes, I noted, thanks for that.
>
> What I have done is running this bat
Hi Jan,
On 30-5-19 14:47, Jan Ceuleers wrote:
Jos, what I think everybody is trying to tell you is that your cron job
has swept the problem under the rug, for now, but that it is still there.
Yes, I noted, thanks for that.
What I have done is running this batch after a Postfix or Dovecot upda
On 30/05/2019 14:41, Jos Chrispijn wrote:
> On 30-5-19 14:25, Wietse Venema wrote:
>> Again, this confirms my suspicion that the system has gotten messed
>> up. Postfix has been around for decennia and it does not require
>> restarts to stay functional.
>
> Ok, thanks y'all for helping out. Everyth
On 30-5-19 14:25, Wietse Venema wrote:
Again, this confirms my suspicion that the system has gotten messed
up. Postfix has been around for decennia and it does not require
restarts to stay functional.
Ok, thanks y'all for helping out. Everything is fine now.
/jos
-- With both feet on the grou
Jos Chrispijn:
> On 30-5-19 13:50, Wietse Venema wrote:
> > On a sane system (LINUX included), Postfix can run without ever
> > needing a baby sitter cronjob.
> OK - never experienced this issue but only for the last few weeks.
What has changed? Not Postfix as far as I can tell.
> > What I suspe
On 30-5-19 13:50, Wietse Venema wrote:
On a sane system (LINUX included), Postfix can run without ever
needing a baby sitter cronjob.
OK - never experienced this issue but only for the last few weeks.
What I suspected was an effed-up system; your need to run a baby
sitter cronjob confirms my su
Jos Chrispijn:
> Wietse, does this match the cause you expected it to be?
On a sane system (LINUX included), Postfix can run without ever
needing a baby sitter cronjob.
What I suspected was an effed-up system; your need to run a baby
sitter cronjob confirms my suspicion.
Are you running Postfix
On 30-5-19 12:52, @lbutlr wrote:
On 30 May 2019, at 02:39, Jos Chrispijn wrote:
Where did that come from? (It doesn't exist on my system).
Amongst others (updating tables), this is now standard on my Postfix
upgrade batch.
I don't know about you, but new aliases and postalias and postmap are t
On 30 May 2019, at 02:39, Jos Chrispijn wrote:
> A friend advised me to run /postfix/update and it looks as if this did the
> trick. Part of that file contains:
>
> newaliases
> postalias hash:/etc/aliases
> postfix reload
> postfix flush
Wher
e did that come from? (It doesn't exist on my syst
On 29-5-19 19:21, Jos Chrispijn wrote:
Interesting that you ask, as I just checked postfix after a restart
and it all goes well again.
Decided to restart from cron every 12 hours, but I guess that is just
symptom suppression
A friend advised me to run /postfix/update and it looks as if this di
On 23-5-19 14:27, Wietse Venema wrote:
It is also possible that your kernel can't handle the exclusive
lock request because it is running out of kernel resources. How
often are you restarting/reloading Postfix?
I have some supicions, but let's hear from you first.
Interesting that you ask, as I
Jos Chrispijn:
> On 22-5-19 13:11, Wietse Venema wrote:
> > postscreen needs exclusive access to the btree file, and some other
> > program other program already has access to the file (exclusive or
> > non-exclusive). That could be another postscreen, or postmap, or
> > some other program.
>
> As
On 22-5-19 13:11, Wietse Venema wrote:
postscreen needs exclusive access to the btree file, and some other
program other program already has access to the file (exclusive or
non-exclusive). That could be another postscreen, or postmap, or
some other program.
As far as I know there are no other
Jos Chrispijn:
> Dear team,
>
> I get this error messages in my logfile more frequently:
>
> May 21 21:23:51 kernel: May 21 21:23:51
> postfix/postscreen[77391]: fatal: btree:/var/db/postfix/postscreen_cache:
> unable to get exclusive lock: Resource temporarily unavailable
postscreen n
Dear team,
I get this error messages in my logfile more frequently:
May 21 21:23:51 kernel: May 21 21:23:51 postfix/postscreen[77391]:
fatal: btree:/var/db/postfix/postscreen_cache: unable to get exclusive lock:
Resource temporarily unavailable
Can you tell me what exactly goes wron
17 matches
Mail list logo
