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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
