[php-maint] Bug#626640: Cron spam

[Bob Proulx]

Marcus Cobden wrote:
> I've been running the updated crontab on a server since my last email and have been getting emails like this from the cron daemon:
> 
> Cannot stat file /proc/8419/fd/1: No such file or directory
> Cannot stat file /proc/8419/fd/2: No such file or directory
> Cannot stat file /proc/8419/fd/3: No such file or directory
> 
> I presume it's fuser printing this as the files its been told to
> look at no longer exist.
> (They've probably been garbage collected by php)

I think that is odd to be getting those messages and I don't
understand why they would be happening.  It wouldn't be from php
garbage collecting.  I think (but am not sure) that it must be a race
between a process active on the session file going away during exit
such that the /proc/$pid still exists but that the files associated
with it have already been cleaned up.  If that is the issue then I
think you must have a very active system indeed to be seeing this with
any regularity.  I have a very quiet system and I have not seen that
message.  I tried to trigger it but was unable to do so. (shrug)

Are you sure the message is coming from fuser?  Can you run the
commands manually and verify this?  I am thinking of something simple
such as this:

  # for f in /var/lib/php5/*; do echo $f; fuser -s $f; done

> Would it be safe to add a "2> /dev/null" to this? Are there any
> other error conditions we might actually want to hear about?

That would probably be fine.  I won't object (like I did before) to
it.  But here is my concern about ignoring errors.

If fuser experiences an error then the exit code will be non-zero.  As
currently constructed if the fuser exit code is non-zero then find
will invoke the -delete action.  If we ignore errors then it is
possible for fuser to *always* experience an error, -delete always to
be called, and no one would ever know.  At that point the reason for
having added the fuser in the first place would not be getting
addressed at all.  In that case it might as well not be there.  It
would be exactly the same as before when you filed the original bug
report.  Since the code needs to work in order to address this problem
that you reported then if we ignore errors it might very well never
actually address the problem.  Ignoring errors historically often
creates situations such as this and so makes me nervous unless it is
fully understood.

Bob