From: Martijn Lievaart on
On Mon, 09 Aug 2010 04:50:35 -0700, Marc Girod wrote:

> Well, I have to figure out how either could be possible. I cannot see
> what in the code could remove anything... Those files are left to be
> accessible from a web page. There is a loop which increments a digit in
> the file name and tries 100 times.
> I don't think this is very smart, but I cannot see how the 100 different
> files could exist.
>
> The error returned in the end is of course only the one for the last
> try.
> So that I don't *know* why the 99 first attempts failed. But in the
> general case, I cannot find the 100th file either.

Stupid suggestion and does not match exactly what you wrote above, but:
Are there maybe two instances of your program running and interfering
with each other?

M4
From: Marc Girod on
On Aug 9, 6:32 pm, Martijn Lievaart <m...(a)rtij.nl.invlalid> wrote:

> Stupid suggestion and does not match exactly what you wrote above, but:
> Are there maybe two instances of your program running and interfering
> with each other?

Thanks... This script is invoked via a ~/.forward file, i.e. for every
incoming mail. I guess it is very possible that the same mail is
presented twice, e.g. if it contains the address twice (?)
Again something I should log.
But each instance generates its own filenames, and sure, the first
would easily clash (protected only by timestamp), but it should impact
only the first of the two instances...

Marc
From: C.DeRykus on
On Aug 10, 12:20 am, Marc Girod <marc.gi...(a)gmail.com> wrote:
> On Aug 9, 6:32 pm, Martijn Lievaart <m...(a)rtij.nl.invlalid> wrote:
>
> > Stupid suggestion and does not match exactly what you wrote above, but:
> > Are there maybe two instances of your program running and interfering
> > with each other?
>
> Thanks... This script is invoked via a ~/.forward file, i.e. for every
> incoming mail. I guess it is very possible that the same mail is
> presented twice, e.g. if it contains the address twice (?)
> Again something I should log.
> But each instance generates its own filenames, and sure, the first
> would easily clash (protected only by timestamp), but it should impact
> only the first of the two instances...
>

Another wild speculation: a .forward loop could bombard
a server with the same message rapidly until the loop's
detected and shutdown. A possible error race condition
might ensue...Still, I suppose a .forward loop shutdown
would've been under the microscope by now.

The added logging/diagnostics should flush this out too.

--
Charles DeRykus
From: Martijn Lievaart on
On Tue, 10 Aug 2010 00:20:34 -0700, Marc Girod wrote:

> On Aug 9, 6:32 pm, Martijn Lievaart <m...(a)rtij.nl.invlalid> wrote:
>
>> Stupid suggestion and does not match exactly what you wrote above, but:
>> Are there maybe two instances of your program running and interfering
>> with each other?
>
> Thanks... This script is invoked via a ~/.forward file, i.e. for every
> incoming mail. I guess it is very possible that the same mail is
> presented twice, e.g. if it contains the address twice (?) Again
> something I should log.
> But each instance generates its own filenames, and sure, the first would
> easily clash (protected only by timestamp), but it should impact only
> the first of the two instances...

In that case I suggest you make sure the filenames are really unique
(hint, use the pid, available in $$), or implement some sort of locking
mechanism.

M4
From: Peter J. Holzer on
On 2010-08-10 22:16, Martijn Lievaart <m(a)rtij.nl.invlalid> wrote:
> On Tue, 10 Aug 2010 00:20:34 -0700, Marc Girod wrote:
>> On Aug 9, 6:32�pm, Martijn Lievaart <m...(a)rtij.nl.invlalid> wrote:
>>> Stupid suggestion and does not match exactly what you wrote above, but:
>>> Are there maybe two instances of your program running and interfering
>>> with each other?
>>
>> Thanks... This script is invoked via a ~/.forward file, i.e. for every
>> incoming mail. I guess it is very possible that the same mail is
>> presented twice, e.g. if it contains the address twice (?) Again
>> something I should log.
>> But each instance generates its own filenames, and sure, the first would
>> easily clash (protected only by timestamp), but it should impact only
>> the first of the two instances...
>
> In that case I suggest you make sure the filenames are really unique
> (hint, use the pid, available in $$),

Since the files are not removed before the program exits, using the pid
doesn't make the filenames unique. Even with a timestamp with a
resolution of one second there is a chance that the pid wraps around too
fast (although it's pretty unlikely).

> or implement some sort of locking
> mechanism.

O_EXCL is "some kind of locking mechanism": Any already existing file is
"locked" and won't be overwritten. It doesn't wait (wouldn't be very
useful since files aren't deleted) but fails immediately. Then the
program tries a new file name. This looks ok (it is also a usual method
for creating temporary files). Maybe the "try next file filename" part
doesn't work correctly - we haven't seen the code and it probably isn't
well tested.

Oh, and for everything running from a .forward file: Be sure to use the
correct exit codes from sys_exit.h.

hp