Mail piler smtp seems to choke on some message-ids?

[Dennis Jasch]

We encountered this a few days ago:

Aug 5 15:51:21 mail-archive piler-smtp[714]: client 59.100.86.131 timeout Aug 5 15:51:21 mail-archive piler-smtp[714]: disconnected from 59.100.86.131 on descriptor 6 (0 active connections) Aug 5 15:51:21 mail-archive piler-smtp[714]: received: ▒Ҁ}▒, from=, size=23172, client=59.100.86.131 Aug 5 15:51:21 mail-archive piler-smtp[714]: ERROR: couldn't rename ▒Ҁ}▒ to 0/▒Ҁ}▒ Aug 5 15:51:21 mail-archive piler-smtp[714]: got signal: 11, Segmentation fault Aug 5 15:51:21 mail-archive piler-smtp[714]: piler-smtp has been terminated

Which led to some mail not being archived, as the broken smtp service hadnt been spotted for a while

1.3.4 build 994

Fresh install with content from previous version migrated into it.

[Janos SUTO]

Is the error message really the following?

▒Ҁ}▒ to 0/▒Ҁ}▒

Try the following:

edit src/misc.c, and locate the move_email() function. Then fix the syslogs line as follows:

syslog(LOG_PRIORITY, "ERROR: couldn't rename %s to %s (reason: %s)", session->ttmpfile, buf, strerror(errno));

Then recompile piler-smtp, and let's see the reason int the logs. Btw. id it for the given message only? (I don't think it has anything to do message-ids)

[Dennis Jasch]

I'm afraid this will be hard to re-produce. The email in question would have been purged. I could not say, which one caused this crash.

Further, Im afraid I could not rebuild this particular instance anytime soon.

I just assumed from other log entries, that this output designates the message-id, would not be sure of this.

[Janos SUTO]

I don't understand. If the move_email() function failed then the problematic email still must be in /var/piler/tmp directory. Anyway if you can't deal with the issue for a while, then no reason to keep it open, so I put it on-hold. Be sure to reopen when you have time for the problem.

[Dennis Jasch]

Sry, but I know next to nothing about Piler internals - how would I reproduced importing that email via smtp?

[Janos SUTO]

Nobody blamed you for not knowing the internals of piler. And nbody wanted you to reproduce anything. What I actually asked is to reopen the ticket when you have time to work on the issue, and then we'll see.

[Dennis Jasch]

I rather meant, I could not really touch that particular system, as it is in production.

But I found the mail in /var/piler/tmp. I can probably send you that per PM, but would not want to publicly post it here. I does not really look abnormal.

[Janos SUTO]

For now I don't need the email. My main concern is the filename. If it's really some garbage, then you must have some issues. The filename should be from the character set A-Z0-9.

The debug info I suggested won't make any harm to your in production archive, it's safe to add. Without it we won't know why it couldn't move the file. Decide how to go on. Anyway consider setting the verbosity level to 5 temporarily, so we'll know more for future issues.

[Dennis Jasch]

The filename in /var/piler/tmp is M3711IHTDNBPVPG0, which seems fairly normal.

Hard to say, what cause above issue - I shall set the debug level.

[Janos SUTO]

OK, then try the following:

mv /var/piler/tmp/M3711IHTDNBPVPG0  /var/piler/tmp/0

Then check the mail logs and verify that it's processed properly.

Btw. it still bothers me how you ended up with ▒Ҁ}▒ in the logs. Also check if /var/piler/tmp has only 0 and 1 dirs and nothing else - provided that it's not processing anything at the moment.

[Dennis Jasch]

Did as instructed, it processed just fine.

My suspicion would be, this mail was one following the "funny" one, and just got stuck in the import process.

tmp only contains 0 and 1, both empty folders.

[Janos SUTO]

OK, then I conclude this issue fixed.