I have also suffered this problem a couple of times, without havving
found anything that would make postgrey to be killed, but today it
happened again and I could read in /var/log/syslog the following:
Jan 14 03:06:03 aragorn postgrey[3477]: cleaning up old logs...
Jan 14 03:06:04 aragorn postgrey[3477]: cleaning up old entries...
Jan 14 03:06:04 aragorn postgrey[3477]: fatal: Can't call method
"txn_commit" on an undefined value at /usr/sbin/postgrey line 199.
I hope it helps, as other people say, postgrey being killed means that
postfix is unable to deliver mail.
Cheers,
--
Jose Carlos Garcia Sogo
js...@debian.org
This is about the postgrey hang that I talked about previously. Really
Annoying. (And I'm still happily running postgrey without any
problems on my own machine, of course...)
From: Jose Carlos Garcia Sogo <js...@debian.org>
> today it happened again and I could read in /var/log/syslog the following:
> Jan 14 03:06:03 aragorn postgrey[3477]: cleaning up old logs...
> Jan 14 03:06:04 aragorn postgrey[3477]: cleaning up old entries...
> Jan 14 03:06:04 aragorn postgrey[3477]: fatal: Can't call method
> "txn_commit" on an undefined value at /usr/sbin/postgrey line 199.
Jose, can you please confirm the versions of the postgrey,
libberkeleydb-perl, libdb4.3, libdb4.4 (depending on the libberkeleydb-perl
verison either of those is used) and perl Debian packages that are
installed on your system?
Anything special about your system? Xen, vmware or whatever? NFS or
some other network based filesystem on the partition where the database
is located?
Just to be safe: below is the diff between postgrey 1.27 and the Debian
version. I changed config file locations and it runs as group postgrey
instead of nogroup. I don't think there is anything that could trigger
this behaviour.
========
--- 1.27/postgrey 2007-01-18 08:56:16.000000000 +0100
+++ 1.27-4/postgrey 2007-01-18 08:58:21.000000000 +0100
@@ -441,8 +441,8 @@
port => [ $opt{inet} ? $opt{inet} : $opt{unix}."|unix" ],
proto => $opt{inet} ? 'tcp' : 'unix',
user => $opt{user} || 'postgrey',
- group => $opt{group} || 'nogroup',
- dbdir => $opt{dbdir} || '/var/spool/postfix/postgrey',
+ group => $opt{group} || 'postgrey',
+ dbdir => $opt{dbdir} || '/var/lib/postgrey',
setsid => $opt{daemonize} ? 1 : undef,
pid_file => $opt{daemonize} ? $opt{pidfile} : undef,
log_level => $opt{verbose} ? 4 : 2,
@@ -453,7 +453,7 @@
},
postgrey => {
delay => $opt{delay} || 300,
- dbdir => $opt{dbdir} || '/var/spool/postfix/postgrey',
+ dbdir => $opt{dbdir} || '/var/lib/postgrey',
max_age => $opt{'max-age'} || 35,
last_maint => time,
last_maint_keys => 0, # do it on the first night
@@ -465,10 +465,11 @@
greylist_action => $opt{'greylist-action'} || 'DEFER_IF_PERMIT',
greylist_text => $opt{'greylist-text'} || 'Greylisted, see http://isg.ee.ethz.ch/tools/postgrey/help/%r.html',
whitelist_clients_files => $opt{'whitelist-clients'} ||
- [ '/etc/postfix/postgrey_whitelist_clients' ,
- '/etc/postfix/postgrey_whitelist_clients.local' ],
+ [ '/etc/postgrey/whitelist_clients' ,
+ '/etc/postgrey/whitelist_clients.local' ],
whitelist_recipients_files => $opt{'whitelist-recipients'} ||
- [ '/etc/postfix/postgrey_whitelist_recipients' ],
+ [ '/etc/postgrey/whitelist_recipients' ,
+ '/etc/postgrey/whitelist_recipients.local' ],
privacy => defined $opt{'privacy'},
hostname => defined $opt{hostname} ? $opt{hostname} : hostname,
exim => defined $opt{'exim'},
@@ -623,8 +624,8 @@
-d, --daemonize run in the background
--pidfile=PATH put daemon pid into this file
--user=USER run as USER (default: postgrey)
- --group=GROUP run as group GROUP (default: nogroup)
- --dbdir=PATH put db files in PATH (default: /var/spool/postfix/postgrey)
+ --group=GROUP run as group GROUP (default: postgrey)
+ --dbdir=PATH put db files in PATH (default: /var/lib/postgrey)
--delay=N greylist for N seconds (default: 300)
--max-age=N delete entries older than N days since the last time
that they have been seen (default: 35)
@@ -635,8 +636,8 @@
(default: Greylisted + help url, see below)
--lookup-by-subnet strip the last 8 bits from IP addresses (default)
--lookup-by-host do not strip the last 8 bits from IP addresses
- --whitelist-clients=FILE default: /etc/postfix/postgrey_whitelist_clients
- --whitelist-recipients=FILE default: /etc/postfix/postgrey_whitelist_recipients
+ --whitelist-clients=FILE default: /etc/postgrey/whitelist_clients
+ --whitelist-recipients=FILE default: /etc/postgrey/whitelist_recipients
--auto-whitelist-clients=N whitelist host after first successful delievery
N is the minimal count of mails before a client is
whitelisted (turned on by default with value 5)
@@ -646,8 +647,9 @@
--exim don't reuse a socket for more than one query (exim compatible)
Note that the --whitelist-x options can be specified multiple times,
- and that per default /etc/postfix/postgrey_whitelist_clients.local is
- also read, so that you can put there local entries.
+ and that per default /etc/postgrey/whitelist_clients.local and
+ /etc/postgrey/whitelist_recipients.local are also read, so that you can put
+ there local entries.
=head1 DESCRIPTION
@@ -673,13 +675,13 @@
=item *
Create a C<postgrey> user and the directory where to put the database I<dbdir>
-(default: C</var/spool/postfix/postgrey>)
+(default: C</var/lib/postgrey>)
=item *
Write an init script to start postgrey at boot and start it. Like this for example:
- postgrey --inet=10023 -d
+ postgrey --inet=60000 -d
=item *
@@ -689,16 +691,16 @@
permit_mynetworks
...
reject_unauth_destination
- check_policy_service inet:127.0.0.1:10023
+ check_policy_service inet:127.0.0.1:60000
=item *
-Install the provided postgrey_whitelist_clients and
-postgrey_whitelist_recipients in /etc/postfix.
+Install the provided whitelist_clients and whitelist_recipients in
+/etc/postgrey.
=item *
-Put in /etc/postfix/postgrey_whitelist_recipients users that do not want
+Put in /etc/postgrey/whitelist_recipients users that do not want
greylisting.
=back
@@ -709,9 +711,10 @@
which no greylisting should be done. Per default postgrey will read the
following files:
- /etc/postfix/postgrey_whitelist_clients
- /etc/postfix/postgrey_whitelist_clients.local
- /etc/postfix/postgrey_whitelist_recipients
+ /etc/postgrey/whitelist_clients
+ /etc/postgrey/whitelist_clients.local
+ /etc/postgrey/whitelist_recipients
+ /etc/postgrey/whitelist_recipients.local
You can specify alternative paths with the --whitelist-x options.
========
--
Today is Pungenday, the 18th day of Chaos in the YOLD 3173
Yeah
jose@aragorn:~$ dpkg-query -W postgrey libberkeleydb-perl libdb4.3
libdb4.4
postgrey 1.27-4
libberkeleydb-perl 0.31-1
libdb4.3 4.3.29-6
libdb4.4 4.4.20-8
jose@aragorn:~$ uname -a
Linux aragorn 2.6.18-3-xen-vserver-amd64 #1 SMP Sun Dec 10 21:15:13 CET
2006 x86_64 GNU/Linux
>
> Anything special about your system? Xen, vmware or whatever? NFS or
> some other network based filesystem on the partition where the database
> is located?
Though there is a Xen kernel running, I don't have any Xen instance
running (a part of dom0), and it is a normal installation, everything
located in the same computer.
--
> This is about the postgrey hang that I talked about previously. Really
> Annoying. (And I'm still happily running postgrey without any
> problems on my own machine, of course...)
Hi, I do not know if this is a regression or what. But since Tuesday I’m
experiencing this postgrey crashes (the same error than José Carlos).
This is the first time it happened on my server:
| Sep 11 02:55:31 bacterio postfix/smtpd[32191]: connect from nixe.bergantells.net[213.239.199.107]
| Sep 11 02:55:31 bacterio postgrey[19113]: action=pass, reason=client whitelist, client_name=nixe.bergantells.net, client_address=213.239.199.107, [...]
| Sep 11 02:55:31 bacterio postgrey[19113]: cleaning up old logs...
| Sep 11 02:55:31 bacterio postgrey[19113]: cleaning up old entries...
| Sep 11 02:55:31 bacterio postgrey[19113]: cleaning main database finished. before: 597, after: 500
| Sep 11 02:55:31 bacterio postgrey[19113]: FATAL: Can't call method "txn_commit" on an undefined value at /usr/sbin/postgrey line 289.
| Sep 11 02:55:32 bacterio postfix/smtpd[32191]: warning: connect to 127.0.0.1:60000: Connection refused
And tonight again:
| Sep 12 02:39:42 bacterio postfix/smtpd[21792]: connect from 89.1.126.105.dynamic.barak-online.net[89.1.126.105]
| Sep 12 02:39:43 bacterio postgrey[7560]: action=greylist, reason=new, client_name=89.1.126.105.dynamic.barak-online.net, client_address=89.1.126.105, [...]
| Sep 12 02:39:43 bacterio postgrey[7560]: cleaning up old logs...
| Sep 12 02:39:43 bacterio postgrey[7560]: cleaning up old entries...
| Sep 12 02:39:43 bacterio postgrey[7560]: cleaning main database finished. before: 138, after: 138
| Sep 12 02:39:43 bacterio postgrey[7560]: FATAL: Can't call method "txn_commit" on an undefined value at /usr/sbin/postgrey line 289.
| Sep 12 02:39:44 bacterio postfix/smtpd[21792]: warning: connect to 127.0.0.1:60000: Connection refused
After it happened the first time yesterday, I wiped the postgrey
database (so hi doubt it would be db corruption).
> Jose, can you please confirm the versions of the postgrey,
> libberkeleydb-perl, libdb4.3, libdb4.4 (depending on the libberkeleydb-perl
> verison either of those is used) and perl Debian packages that are
> installed on your system?
These are the versions of the packages you asked Jose:
| # dpkg-query -W postgrey libberkeleydb-perl libdb4.3 libdb4.4 perl
| libberkeleydb-perl 0.31-1
| libdb4.3 4.3.29-9
| libdb4.4 4.4.20-9
| perl 5.8.8-7
| postgrey 1.31-1
| # uname -a
| Linux bacterio 2.6.22.6 #1 Fri Aug 31 13:16:16 CEST 2007 i686 GNU/Linux
> Anything special about your system? Xen, vmware or whatever? NFS or
> some other network based filesystem on the partition where the database
> is located?
Kernel is a vanilla (from kernel.org) compiled by myself, I do not use
Xen and the db resides on a normal ide disk on the local machine.
I kwnow it’s not too much information I’m providing, as this is highly
annoying I would be very glad to test anything or provide any additional
information you should need.
Thanks in advance.
--
Kiko
Hi,
we are at 1.32-4 and I've been running 1.31 without problems for months on some
Debian servers, can you please let us know if you're still experiencing this
problem?
Cheers
Antonio
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sorry, but I am not using postgrey anymore, as I don't have now a home server.
Cheers,
--
José Carlos García Sogo
js...@debian.org