in reply to Safe::Logs - Feedback appreciated

This comment has nothing to do with protecting broken terms (replace 'em!).

It's rare and may be difficult to test, so it's a common vulnerability. What happens if the logging device fills up? On a machine with /dev/full (Linux and a few others may have it), you can say:

{ open local(*LOG), '>>', '/dev/full' or die $!; # run tests }
That will cause prints to LOG in the test code to fail on flush with $! = ENOSPC. That may happen either in the print, or on closing the handle.

As always, ignoring errors on system calls can lead to Bad Things.

Update: ++premchai21 for catching an embarassing typo that turned /dev/full into the useless-for-this /dev/null. Easy to see where that came from!.

Here's an example of the kind of thing to watch for. STDERR is reopened to be a dupe of the LOG handle: print LOG $@ or die $!; # d'oh!

After Compline,
Zaxo

Replies are listed 'Best First'.
Re: Safe::Logs - Feedback appreciated
by jonadab (Parson) on Mar 04, 2003 at 13:30 UTC
    What happens if the logging device fills up?

    I was under the impression that most modern systems had limits on the max sizes of the logfiles and that the logging mechanism would automagically rotate the logs as necessary. It certainly ought to be that way.

    OTOH, before I started using Linux I was also under the impression that modern systems would automagically use available drive space to create swap space as needed...


    for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc' .'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$ p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}