maildrop "Unable to write to temporary file"

Raze

New Member
Hallo,

seit ein paar Tagen schlage ich mit maildrop und größeren Anhängen rum.

maildrop steigt mit folgender Fehlermeldung aus:

Code:
temporary failure. Command output: /usr/bin/maildrop: Unable to write to temporary file - possibly out of disk space.

df -h
Code:
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda4             227G   37G  191G  17% /
udev                   10M   84K   10M   1% /dev
/dev/sda3             2.0G  4.6M  2.0G   1% /tmp
/dev/sda1             129M   21M  108M  17% /boot

strace (der Anhang entstammt /dev/zero, daher "AAAAAA..." ;) )
Code:
poll([{fd=13, events=POLLOUT}], 1, 1000000) = 1 ([{fd=13, revents=POLLOUT}])
write(13, "AAAAA\nAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = 4096
read(11, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = 4096
poll([{fd=13, events=POLLOUT}], 1, 1000000) = 1 ([{fd=13, revents=POLLOUT}])
write(13, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = 4096
read(11, "AAAAAAANHAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = 4096
poll([{fd=13, events=POLLOUT}], 1, 1000000) = 1 ([{fd=13, revents=POLLERR}])
--- SIGCHLD (Child exited) @ 0 (0) ---
write(13, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
close(13)                               = 0
poll([{fd=14, events=POLLIN}], 1, 1000000) = 1 ([{fd=14, revents=POLLIN|POLLHUP}])
read(14, "/usr/bin/maildrop: Unable to writ"..., 4096) = 83
poll([{fd=14, events=POLLIN}], 1, 1000000) = 1 ([{fd=14, revents=POLLHUP}])
read(14, ""..., 4096)                   = 0
close(14)                               = 0
rt_sigaction(SIGALRM, {0x80684a0, [], 0}, {0x806c310, [], SA_RESTART}, 8) = 0
alarm(1000)                             = 5976
waitpid(22053, [{WIFEXITED(s) && WEXITSTATUS(s) == 75}], 0) = 22053
alarm(0)                                = 1000
rt_sigaction(SIGALRM, {0x806c310, [], SA_RESTART}, NULL, 8) = 0
alarm(5976)                             = 0
socket(PF_FILE, SOCK_STREAM, 0)         = 12
fcntl64(12, F_GETFL)                    = 0x2 (flags O_RDWR)
fcntl64(12, F_SETFL, O_RDWR)            = 0
connect(12, {sa_family=AF_FILE, path="private/defer"...}, 110) = 0
gettimeofday({1245444137, 742458}, NULL) = 0
poll([{fd=12, events=POLLOUT}], 1, 3600000) = 1 ([{fd=12, revents=POLLOUT}])
write(12, "nrequest\0000\0flags\0000\0queue_id\0E1788"..., 444) = 444
gettimeofday({1245444137, 742696}, NULL) = 0
poll([{fd=12, events=POLLIN}], 1, 3600000) = 1 ([{fd=12, revents=POLLIN|POLLHUP}])
read(12, "status\0000\0\0"..., 4096)    = 10
gettimeofday({1245444137, 768160}, NULL) = 0
close(12)                               = 0
gettimeofday({1245444137, 768210}, NULL) = 0
time(NULL)                              = 1245444137
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2295, ...}) = 0
send(7, "<22>Jun 19 22:42:17 postfix/pipe["..., 283, MSG_NOSIGNAL) = 283
poll([{fd=10, events=POLLOUT}], 1, 3600000) = 1 ([{fd=10, revents=POLLOUT}])
write(10, "status\0\0diag_type\0\0diag_text\0\0mta"..., 86) = 86
gettimeofday({1245444137, 768561}, NULL) = 0
poll([{fd=10, events=POLLIN}], 1, 3600000) = 1 ([{fd=10, revents=POLLIN|POLLHUP}])
read(10, ""..., 4096)                   = 0
close(11)                               = 0
close(10)                               = 0
write(5, "\216U\0\0\21\0\0\0\1\0\0\0"..., 12) = 12
time(NULL)                              = 1245444137
alarm(0)                                = 5976
flock(8, LOCK_EX^C <unfinished ...>
Process 21902 detached

Leider kann ich zu dem Problem absolut nichts finden, es dreht sich meißt um wirklich volle Festplatten oder aber gänzlich andere Dinge. Rechte sollten auch alle korrekt sein, da ansonsten wohl eine andere Fehlermeldung ausgegeben werden würde. Siehe:

SfR Fresh: [maildrop-2.1.0.tar.gz] Member message.C (maildrop-2.1.0/maildrop ...
Code:
#if	SHARED_TEMPDIR
  125 
  126 		fd=tempfile.Open();
  127 
  128 		if (fd < 0)
  129 			throw "Unable to create temporary file.";
  130 #else
  131 		while ( (fd=tempfile.Open( TempName(),
  132 			O_RDWR | O_CREAT | O_EXCL, 0600)) < 0 &&
  133 			errno == EEXIST)
  134 			;
  135 		if (fd < 0)
  136 			throw "Unable to create temporary file - check permissions on $HOME/" TEMPDIR;
  137 #endif
  138 
  139 		mio.fd(fd);
  140 
  141 		if ((off_t)mio.write(buffer, msgsize) != msgsize)
  142 			throw "Unable to write to temporary file - possibly out of disk space.";
  143 
  144 		delete[] buffer;
  145 		buffer=0;
  146 	}

MTA ist Postfix:

postconf -n
Code:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
anvil_rate_time_unit = 60
bounce_queue_lifetime = 6h
bounce_size_limit = 2147483648
bounce_template_file = /etc/postfix/bounce.cf
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
debug_peer_level = 2
default_process_limit = 200
default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason} - see http://$rbl_domain or http://postmaster.ABC.de/rbl/$rbl_what/$rbl_domain
header_checks = pcre:/etc/postfix/header_checks.pcre
home_mailbox = .maildir/
html_directory = /usr/share/doc/postfix-2.4.5/html
inet_interfaces = all
mail_owner = postfix
mailbox_size_limit = 2147483648
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 4d
message_size_limit = 2147483648
myhostname = server.ABC
mynetworks = 127.0.0.0/8
newaliases_path = /usr/bin/newaliases
proxy_read_maps = $local_recipient_maps,    $mydestination,    $virtual_alias_maps,    $virtual_uid_maps,    $virtual_gid_maps,    $virtual_alias_domains,    $virtual_mailbox_maps,    $virtual_mailbox_domains,    $relay_recipient_maps,    $relay_domains,    $canonical_maps,    $sender_canonical_maps,    $recipient_canonical_maps,    $relocated_maps,    $mynetworks
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.4.5/readme
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtp_connect_timeout = 10
smtp_helo_timeout = 60
smtpd_client_connection_count_limit = 25
smtpd_client_connection_rate_limit = 120
smtpd_data_restrictions = permit_mynetworks,    permit_sasl_authenticated,    reject_multi_recipient_bounce,    reject_unauth_pipelining
smtpd_hard_error_limit = 5
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,    permit_sasl_authenticated,    reject_invalid_helo_hostname,    reject_non_fqdn_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks,    permit_sasl_authenticated,    reject_unlisted_recipient,    check_policy_service unix:private/whitelist,    check_recipient_access mysql:/etc/postfix/virtual_blacklist_maps.cf,    check_recipient_access mysql:/etc/postfix/virtual_rfc_recipient_maps.cf,    check_policy_service inet:127.0.0.1:10031,    check_recipient_access mysql:/etc/postfix/virtual_amavis_maps.cf,    reject_unauth_destination
smtpd_reject_unlisted_sender = no
smtpd_restriction_classes = check_blacklist,    check_rfc_recipient
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sender_restrictions = permit_mynetworks,    permit_sasl_authenticated,    reject_non_fqdn_sender,    reject_unknown_sender_domain
smtpd_soft_error_limit = 10
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = proxy:mysql:/etc/postfix/virtual_alias_maps.cf
virtual_gid_maps = proxy:mysql:/etc/postfix/virtual_gid_maps.cf
virtual_mailbox_base = /
virtual_mailbox_domains = ABC.de, proxy:mysql:/etc/postfix/virtual_domains_maps.cf
virtual_mailbox_limit = 1073741824
virtual_mailbox_limit_override = yes
virtual_mailbox_maps = mysql:/etc/postfix/virtual_mailbox_maps.cf
virtual_maildir_limit_message = Sorry, the user's MailBox has overdrawn his diskspace quota, please try again later. Der Speicherplatz des Postfachs wurde ueberschritten. Bitte versuchen Sie es spaeter erneut.
virtual_minimum_uid = 100
virtual_overquota_bounce = no
virtual_transport = maildrop
virtual_uid_maps = proxy:mysql:/etc/postfix/virtual_uid_maps.cf

Funktioniert auch alles prima, nur eben der maildrop mit größeren Anhängen bereitet Probleme. Ich bin mit meinem Latein recht am Ende.

Wo genau möchte maildrop denn die temporären Dateien erstellen? /var/spool/postfix/maildrop ?

Code:
ls -la
total 12
drwxr-xr-x 16 root    root     4096 Jan 20 18:28 .
drwxr-xr-x  8 root    root       92 Jan 20 14:40 ..
-rw-r--r--  2 root    root        0 Sep 30  2008 .keep_mail-mta_postfix-0
drwx------  2 postfix root        6 Jun 22 14:56 active
drwx------  2 postfix root        6 Jun 22 14:49 bounce
drwx------  2 postfix root        6 Jan 20 18:28 corrupt
drwx------ 18 postfix root      134 May 20 18:37 defer
drwx------ 18 postfix root      134 May 20 18:37 deferred
drwx------  2 postfix root        6 Jan 20 18:28 flush
drwx------  2 postfix root        6 Jan 20 18:28 hold
drwx------  2 postfix root        6 Jun 22 14:56 incoming
drwx-wx---  2 postfix postdrop    6 Jun 22 13:19 maildrop
drwxr-xr-x  2 root    root     4096 Apr  7 11:43 pid
drwx------  2 postfix root     4096 Jun 22 12:38 private
drwx--x---  2 postfix postdrop   68 Jun 22 12:38 public
drwx------  2 postfix root        6 Jan 20 18:28 saved
drwx------  2 postfix root        6 Jun 22 11:10 trace

Hoffe jemand hat eine Idee / Ansatz für mich, derweil bin ich wirklich am verzweifeln ;)
 
Jup, rennt ebenso problemlos.

cat /proc/mounts
Code:
rootfs / rootfs rw 0 0
/dev/sda4 / xfs rw,noatime,usrquota,prjquota,grpquota 0 0
/proc /proc proc rw,nosuid,nodev,noexec 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,nosuid,size=10240k,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
/dev/sda3 /tmp xfs rw,nosuid,noexec,noatime,usrquota,prjquota,grpquota 0 0
/dev/sda1 /boot xfs rw,noatime,noquota 0 0

repquota -a , um die Useraccounts gekürzt (keiner überschreitet auch nur annährend das Limit)

Code:
*** Report for user quotas on device /dev/sda4
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      -- 2816256       0       0         185377     0     0
lp        --       0       0       0              1     0     0
mail      --      24       0       0              7     0     0
postmaster --    1636       0       0            404     0     0
portage   --  370608       0       0          66570     0     0
nobody    --       0       0       0              1     0     0
ntp       --       0       0       0              1     0     0
dhcp      --       0       0       0              2     0     0
ldap      --      16       0       0              9     0     0
clamav    --   47968       0       0             12     0     0
apache    --   33664       0       0            762     0     0
mysql     --  935648       0       0           2137     0     0
amavis    --   46892       0       0             42     0     0
postfix   --  254432       0       0             82     0     0


*** Report for user quotas on device /dev/sda3
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      --       4       0       0              6     0     0
apache    --      36       0       0              3     0     0
mysql     --      64       0       0              5     0     0
 
Ans tmp-Verzeichnis des Postfaches hab ich mich schon mit

Code:
watch -n1 "ls -la"

angehangen. Fehlanzeige, dort wird nichts erstellt.

€dit:

Habe soeben mal ein

Code:
chattr +ai
aufs tmp-Verzeichnis gelegt gehabt, der Fehler bleibt der gleiche, ergo kein Zugriffproblem, ergo soll das File in einem anderen Verzeichnis abgelegt werden. Nur wo :confused: Die üblichen Verdächtigen ( /tmp, /var/tmp ) kann ich ausschließen.
 
Last edited by a moderator:
Da Du strace schon eingesetzt hast, sollte es für Dich kein Problem darstellen, diesen Fragen zu beantworten ;) Der Systemcall heißt "open".
 
cat strace | grep open

Code:
open("active/E75AAC034762", O_RDWR|O_LARGEFILE) = 11

Das geschieht nach einem "mail -q", in dem Moment werden die Mails (ich hab 2 in der Queue, nach "/var/spool/postfix/active" verschoben und von dort eingelesen, beide Files sind dann Ihre ~130MB groß, der Anhang selbst ist etwas kleiner, eben Base64 encoded ..

Die Calls "write" oder "close" bringen mich leider nicht weiter, der strace ist da nichtssagend:

write
Code:
write(13, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = 4096
write(13, "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = 4096
.
.
.
write(12, "nrequest\0000\0flags\0000\0queue_id\0E75AA"..., 444) = 444
write(10, "status\0\0diag_type\0\0diag_text\0\0mta"..., 86) = 86
write(5, "\6R\0\0?\n\0\0\1\0\0\0"..., 12) = 12

close
Code:
close(12)                               = 0
close(15)                               = 0
close(13)                               = 0
close(14)                               = 0
close(12)                               = 0
close(11)                               = 0
close(10)                               = 0
 
Du schaust hier zwei unterschiedliche Filedescriptoren an. Das liefert keine brauchbaren Ergebnisse...
Code:
open("active/E75AAC034762", O_RDWR|O_LARGEFILE) = [COLOR="Red"]11[/COLOR]
[...]
write([COLOR="Red"]13[/COLOR], "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"..., 4096) = 4096
Hast Du strace auch angewiesen, neuen Prozessen zu folgen (-f)? Sieht nicht so ganz danach aus, da am Zeilenanfang keine Prozess-IDs stehen.
 
:eek:

Auch wenn wir beide am Problem vorbei geforscht haben, hat dein Hinweis mich dann doch in die richtige Richtung gelenkt ..

Dem strace konnte ich entnehmen dass die temp-Files doch unter /tmp abgelegt werden, muss ich wohl Tomaten auf den Augen gehabt haben.

Ein xfs_check & xfs_repair auf der Partition hat zwar nichts weiter gebracht, aber nachdem ich die Partition unmountet habe und das /tmp-Folder auf /dev/sda4 nutze, funktionierts.

Obs nun letztlich ein Quota-Problem war, was ich nicht glaube, da keine Limits gesetzt sind

Code:
*** Report for user quotas on device /dev/sda3
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      --       4       0       0              6     0     0
apache    --      36       0       0              3     0     0
mysql     --      64       0       0              5     0     0

oder ein FS-Problem war / ist, werd ich nun eruieren.
 
Nachdem ich Quota für /dev/sda3 deaktiviert habe funktionierts problemlos. Bisher nie ein solches Problem gehabt, zumal wie gesehen ja keinerlei Quotalimits auf dem Device erstellt waren.

Eine plausible Erklärung dafür würde mich echt noch interessieren ..
 
Back
Top