A NOTE has been added to this issue. ====================================================================== http://dbmail.org/mantis/view.php?id=511 ====================================================================== Reported By: Anne Assigned To: aaron ====================================================================== Project: DBMail Issue ID: 511 Category: LMTP daemon Reproducibility: always Severity: major Priority: normal Status: feedback target: ====================================================================== Date Submitted: 22-Feb-07 13:44 CET Last Modified: 05-Mar-07 22:10 CET ====================================================================== Summary: when filesystem is full, only header block is inserted Description: When /tmp has unsufficient diskspace, dbmail inserts only the header block.
dbmail 2.2.2, Postfix 2.3.7, Mysql 5.0.27, Amavis 2.4.2, p5-Mail-SpamAssassin-3.1.8 ====================================================================== ---------------------------------------------------------------------- aaron - 22-Feb-07 17:08 ---------------------------------------------------------------------- Line 38 of the log file doesn't look good: Feb 22 11:12:48 NBMS02 dbmail/lmtpd[93842]: Debug:[lmtp] lmtp.c,lmtp(+563): whole message = ---------------------------------------------------------------------- aaron - 22-Feb-07 17:14 ---------------------------------------------------------------------- Line 360 of dbmail-message.c writes the incoming email to a file handle gotten from the tmpfile() call, but does not have any error checking to make sure that the write succeeded (did not return -1) or write enough bytes (not sure how to check, given the code at hand in _set_content_from_stream) http://spruce.sourceforge.net/gmime/doc/gmime-gmime-stream.html#g-mime-stream-write-string ---------------------------------------------------------------------- aaron - 03-Mar-07 18:15 ---------------------------------------------------------------------- Committed a possible fix. It passes all checks, but needs some testing. Please upgrade to dbmail_2_2_branch, if you can. ---------------------------------------------------------------------- Anne - 04-Mar-07 16:54 ---------------------------------------------------------------------- I tested with the latest dbmail_2_2_branch. Still the same problem. NBMS02# grep [EMAIL PROTECTED] maillog Mar 4 16:13:10 NBMS02 dbmail/lmtpd[62671]: Debug:[lmtp] lmtp.c,lmtp(+255): incoming buffer: [MAIL FROM:<[EMAIL PROTECTED]>] Mar 4 16:13:10 NBMS02 dbmail/lmtpd[62671]: Debug:[lmtp] lmtp.c,lmtp(+269): command issued :cmd [MAIL], value [FROM:<[EMAIL PROTECTED]>] Mar 4 16:13:10 NBMS02 dbmail/lmtpd[62671]: Info:[misc] misc.c,find_bounded(+374): Found [EMAIL PROTECTED] of length [18] between '<' and '>' so next skip [24] Mar 4 16:13:10 NBMS02 dbmail/lmtpd[62671]: Debug:[sql] dbmysql.c,db_query(+286): query [INSERT INTO dbmail_messageblks (is_header, messageblk,blocksize, physmessage_id) VALUES (1,'Return-Path: [EMAIL PROTECTED]: 2602\nMessage-Id: <1173021190l.62671l.0l@>\nMIME-Version: 1.0\n\n', 118, 2602)] NBMS02# Note: I didn't cut any log lines. It looks a lot shorter than before... Note 2: I will be on holidays next two weeks, so I won't be able to test any additional changes. ---------------------------------------------------------------------- aaron - 05-Mar-07 21:05 ---------------------------------------------------------------------- Really, really, really bad situation here: the code in _set_content_from_stream is entirely unable to detect short writes. Somehow, with the sequence of filters we've built up, the function g_mime_stream_write_string(fstream, buf) (around line 380 of dbmail-message.c) always returns the length of the buffer even when nothing was written to disk. Either this is a gmime bug (my gmime is 2.2.3, btw) or we're abusing gmime in some wrong way. ---------------------------------------------------------------------- aaron - 05-Mar-07 22:10 ---------------------------------------------------------------------- More fundamental problem: linux fwrite doesn't fail apparently until the C library's internal buffers are full and flushed to disk. At that point, the next fwrite will return 0. So we need a broader strategy for allocating space before filling it, or -- what about the memory stream code that's commented out? Issue History Date Modified Username Field Change ====================================================================== 22-Feb-07 13:44 Anne New Issue 22-Feb-07 13:44 Anne File Added: maillog 22-Feb-07 17:08 aaron Note Added: 0001831 22-Feb-07 17:14 aaron Note Added: 0001832 03-Mar-07 18:15 aaron Status new => resolved 03-Mar-07 18:15 aaron Fixed in Version => 2.2.4 03-Mar-07 18:15 aaron Resolution open => fixed 03-Mar-07 18:15 aaron Assigned To => aaron 03-Mar-07 18:15 aaron Note Added: 0001854 04-Mar-07 16:27 Anne Status resolved => feedback 04-Mar-07 16:27 Anne Resolution fixed => reopened 04-Mar-07 16:27 Anne Note Added: 0001858 04-Mar-07 16:28 Anne Note Edited: 0001858 04-Mar-07 16:28 Anne Note Edited: 0001858 04-Mar-07 16:54 Anne Note Edited: 0001858 05-Mar-07 21:05 aaron Note Added: 0001864 05-Mar-07 22:10 aaron Note Added: 0001866 ====================================================================== _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
