[php-maint] Bug#626640: Bug#626640: Cron spam

[Ondřej Surý]

Hi,

yes, it looks like race condition in fuser.c indeed...

But it needs to be fixed in psmisc.

You can silence your cron by doing:

fuser -s {} 2>/dev/null

But I think the correct way is to fix fuser to not print the error in
case of ENOENT (See #629048).

O.

On Mon, May 23, 2011 at 19:10, Bob Proulx <bob at proulx.com> wrote:
> 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
>
>
>
> _______________________________________________
> pkg-php-maint mailing list
> pkg-php-maint at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-php-maint
>



-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/