Is the app somehow able to keep running even when the filesystem is overwhelmed? Does the system never shut down at all? Is there no maintenance window, power outage or any other interruption in this critical app's operation?

Surely there must be a point when the app stops, and when that happens, reconfigure its logging protocol before it starts again. Have its log output write to some sort of log rotation tool, as suggested above.

As for your failed attempts to truncate the log file, perhaps this is a permission issue? What user/group owns the file and the directory that contains it? What are the permission modes on the file and on the directory that contains it? A user with adequate permission should be able to truncate the file. (Before truncating it, is it being backed up, and is that important?)

Update: this is turning out to be a non-perl problem, unless you want to ask about how to re-invent log rotation in perl. Your options depend on knowing more about the app that is generating all this log data (and since it's not a perl app, we aren't talking about perl questions). You need to know things like:

Is it a daemon that starts at boot time, or is it started some other way? Is there no control over the amount of logging output (either a config file or command line options at startup)? Does it require a specific file path/name to be the log file, or is it simply being started with stdout and/or stderr being redirected to this "overwhelming" file? Is the log info really useless (could you just redirect it to /dev/null)?

Chances are, if you learn about that stuff, you'll find out how to solve the problem.