Subject: Postfix or amavis troubles after kernel upgrade
From: Gilles Sadowski <gilles@harfang.homelinux.org>
Date: Thu, 10 Apr 2008 01:50:31 +0200

Hello.

I had been running postfix and amavis inside a vserver for quite some time.
This was under a debian vserver-enabled kernel (2.6.22).

Yesterday I compiled the latest stable kernel (2.6.24.4) from kernel.org,
patched with "patch-2.6.24.4-vs2.3.0.34.diff" found on the vserver web site.
Booting with this new kernel, the problem is that all mail is now blocked
at some step of the delivery, as shown in the following log message:

---
mail.info: Apr 10 00:56:19 postfix/smtp[18586]: 13DEF2DD5: to=<gilles@harfang.homelinux.org>,
relay=none, delay=1023, delays=1023/0.01/0/0, dsn=4.4.1, status=deferred (connect to
192.168.20.11[192.168.20.11]: Connection refused)
---

To be sure, I rebooted with the old kernel, and all other things being
equal, the mail is then delivered:

---
mail.info: Apr 10 01:15:45 postfix/smtp[19002]: 13DEF2DD5: to=<gilles@harfang.homelinux.org>,
relay=192.168.20.11[192.168.20.11]:10024, delay=2189, delays=2184/0.09/0/4.7, dsn=2.6.0,
status=sent (250 2.6.0 Ok, id=06081-03, from MTA([192.168.20.11]:10025): 250 2.0.0 Ok:
queued as E975D3C6A)
---

This is the vserver-related kernel config, in the case where it all works:

---
# CONFIG_VSERVER_LEGACY is not set
# CONFIG_VSERVER_LEGACYNET is not set
# CONFIG_VSERVER_REMAP_SADDR is not set
CONFIG_VSERVER_COWBL=y
# CONFIG_VSERVER_VTIME is not set
CONFIG_VSERVER_PROC_SECURE=y
CONFIG_VSERVER_HARDCPU=y
# CONFIG_VSERVER_IDLETIME is not set
CONFIG_VSERVER_IDLELIMIT=y
CONFIG_VSERVER_PRIVACY=y
CONFIG_VSERVER_CONTEXTS=768
CONFIG_VSERVER_WARN=y
# CONFIG_VSERVER_DEBUG is not set
CONFIG_VSERVER=y
CONFIG_VSERVER_SECURITY=y
CONFIG_VSERVER_NGNET=y
---

And this is the config that gives the problem described:

---
CONFIG_VSERVER_AUTO_LBACK=y
CONFIG_VSERVER_AUTO_SINGLE=y
CONFIG_VSERVER_COWBL=y
# CONFIG_VSERVER_VTIME is not set
CONFIG_VSERVER_DEVICE=y
CONFIG_VSERVER_PROC_SECURE=y
CONFIG_VSERVER_HARDCPU=y
# CONFIG_VSERVER_IDLETIME is not set
# CONFIG_VSERVER_IDLELIMIT is not set
CONFIG_VSERVER_PRIVACY=y
CONFIG_VSERVER_CONTEXTS=768
CONFIG_VSERVER_WARN=y
# CONFIG_VSERVER_DEBUG is not set
CONFIG_VSERVER=y
CONFIG_VSERVER_SECURITY=y
---

Is there something I can change in the above to get it working as before
but with the new kernel?
Or maybe there is something now to be explicitely added in the vserver
config directory?

Thanks for any hint on the likely cause of this change of behaviour.

Best,
Gilles