(sorry for the message without subject)

Since we rebooted our servers to go to Linux version 2.6.11-rc1 (minor
update for a security fix) on a Debian Woody system, we cannot send nor
receive email anymore.

The clients are getting a "451 Error: queue file write error", syslog giv=
es
messages like this:

Jan 15 07:11:46 pomo postfix/cleanup[5044]: warning: 707E4D00664D: write
queue file: Resource temporarily unavailable=20

There is also another similar message in syslog:

Jan 15 06:59:44 pomo postfix/bounce[30065]: fatal: append file defer
C8EEFD001DA3: Resource temporarily unavailable

The postfix config was not changed since it worked.  I googled for "write
queue file: Resource temporarily unavailable" with not useful result.=20
Either part separately has oodles of hits, but they are unrelated to our
problem.

postconf -n says:

alias_database =3D hash:/etc/aliases
alias_maps =3D hash:/etc/aliases
append_dot_mydomain =3D no
biff =3D no
broken_sasl_auth_clients =3D no
canonical_maps =3D hash:/etc/postfix/canonical
command_directory =3D /usr/sbin
config_directory =3D /etc/postfix
daemon_directory =3D /usr/lib/postfix
home_mailbox =3D Maildir/
lmtp_sasl_auth_enable =3D yes
mailbox_command =3D=20
message_size_limit =3D 16384000
mydestination =3D $myhostname, localhost.$mydomain, h02.hostsharing.net
mynetworks =3D 127.0.0.0/8
myorigin =3D /etc/mailname
notify_classes =3D resource, software
program_directory =3D /usr/lib/postfix
recipient_delimiter =3D +
relayhost =3D=20
setgid_group =3D postdrop
smtp_bind_address =3D 212.21.77.2
smtp_sasl_auth_enable =3D no
smtpd_banner =3D $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_restrictions =3D permit_mynetworks
smtpd_helo_restrictions =3D reject_invalid_hostname
smtpd_recipient_restrictions =3D
 permit_sasl_authenticated				permit_myne
tworks				check_client_access
btree:/var/lib/drac/dracd				check_relay_domains
smtpd_sasl_auth_enable =3D yes
smtpd_sasl_local_domain =3D $myhostname
smtpd_sasl_security_options =3D noanonymous
smtpd_sender_restrictions =3D reject_unknown_sender_domain,
reject_invalid_hostname
transport_maps =3D hash:/etc/postfix/transport
virtual_maps =3D hash:/etc/postfix/virtual

Any idea? Thanks a lot!

Michael


--=20
--=20
http://www.hostsharing.org - Webhosting Spielregeln selbst=20
definiert
http://www.binational-in.de - f=FCr binationale Paare und Familien=20
in D
http://www.hoennig.de -- Michael H=F6nnig/Boytinstr. 10/D-22143=20
Hamburg=20

[ Post a follow-up to this message ]

* michael.hoennig@gmx.de <michael.hoennig@gmx.de>:
> (sorry for the message without subject)
>
> Since we rebooted our servers to go to Linux version 2.6.11-rc1 (minor
> update for a security fix) on a Debian Woody system, we cannot send nor
> receive email anymore.
>
> The clients are getting a "451 Error: queue file write error", syslog give
s
> messages like this:
>
> Jan 15 07:11:46 pomo postfix/cleanup[5044]: warning: 707E4D00664D: wri
te
> queue file: Resource temporarily unavailable
>
> There is also another similar message in syslog:
>
> Jan 15 06:59:44 pomo postfix/bounce[30065]: fatal: append file defer
> C8EEFD001DA3: Resource temporarily unavailable

Reboot your server, perform a forced full fsck of the partition the queue is
on.

--
Ralf Hildebrandt (Ralf.Hildebrandt@charite.de)          spamtrap@charite.de
http://www.arschkrebs.de/postfix/                Tel. +49 (0)30-450 570-155
I have a spelling checker - It came with my PC;
It plainly marks four my revue - Mistakes I cannot sea.
I've run this poem threw it, I'm sure your pleased too no,
Its letter perfect in it's weigh, My checker tolled me sew.   -- Janet Minor

[ Post a follow-up to this message ]

Hi Ralf,
 
>
> Reboot your server, perform a forced full fsck of the partition the
> queue is on.

fsck would not help on our XFS filesystems.  But you are probably right
that it is a fs problem.  Going back to our old kernel fixed this problem,
but now XFS quota is damaged.  I guess,  Linux 2.6.11-rc1 has a problem
with XFS.

It's just strange that we could manually wirte into the spool as user
postfix without problems, jus postfix could not.

Thanks!
Michael

[ Post a follow-up to this message ]

Michael Hoennig:
> Hi Ralf,
> 
>
> fsck would not help on our XFS filesystems.  But you are probably right
> that it is a fs problem.  Going back to our old kernel fixed this problem,
> but now XFS quota is damaged.  I guess,  Linux 2.6.11-rc1 has a problem
> with XFS.
>
> It's just strange that we could manually wirte into the spool as user
> postfix without problems, jus postfix could not.

Postfix cleanup(8) does not only use write(2). It also uses lseek(2)
and fsync(2), and will run into the file size limit for large mail.
All this is are more complex and less used than write(2).

The Linux XFS developers need to test their code before release.

Wietse

[ Post a follow-up to this message ]

Michael Hoennig:
> Hi Ralf,
> 
>
> fsck would not help on our XFS filesystems.  But you are probably right
> that it is a fs problem.  Going back to our old kernel fixed this problem,
> but now XFS quota is damaged.  I guess,  Linux 2.6.11-rc1 has a problem
> with XFS.
>
> It's just strange that we could manually wirte into the spool as user
> postfix without problems, jus postfix could not.

Postfix cleanup(8) does not only use write(2). It also uses lseek(2)
and fsync(2), and will run into the file size limit for large mail.
All this is are more complex and less used than write(2).

The Linux XFS developers need to test their code before release.

Wietse

[ Post a follow-up to this message ]

Michael Hoennig:
> Hi Ralf,
> 
>
> fsck would not help on our XFS filesystems.  But you are probably right
> that it is a fs problem.  Going back to our old kernel fixed this problem,
> but now XFS quota is damaged.  I guess,  Linux 2.6.11-rc1 has a problem
> with XFS.
>
> It's just strange that we could manually wirte into the spool as user
> postfix without problems, jus postfix could not.

Postfix cleanup(8) does not only use write(2). It also uses lseek(2)
and fsync(2), and will run into the file size limit for large mail.
All this is are more complex and less used than write(2).

The Linux XFS developers need to test their code before release.

Wietse

[ Post a follow-up to this message ]

Wietse Venema wrote:
> Michael Hoennig:
[] 
[][vbcol=seagreen]
> The Linux XFS developers need to test their code before release.

JFYI: this is not a release we're talking about, it's sort of a
development snapshot of the kernel.

/mjt

[ Post a follow-up to this message ]