I run a particular abandoned open source project (StreamBaby) on my home media server, a Mac Mini. It's awesome but has one unfortunate issue which occasionally causes the app to generate an absolutely massive error log - like on the order of many tens of gigabytes. Sometimes by the time I notice it, it's well over 100GB. All I have to do is delete it and restart the service and all is fine, but obviously problems can arise if the drive runs out of space due to this.

I'd like to monitor this file and any time it's larger than maybe 10MB, alert me in some fashion (beep, send an email, pop an alert... something). I've found services that will monitor if a file size has changed, but I need to monitor it for a specific size.

Can this be done via Automator, AppleScript, or some other means?

  • Just a thought: do yo need the error log at all or could you link it to /dev/null? – nohillside Sep 13 '15 at 4:21
  • I'm not sure if it's required, it's not technically an error log per se, just a general log file that the service creates (assuming it's missing) when it runs. I'm not sure what would happen if it wasn't written, but I'd be game to try it. There's nothing useful in it for me anyway, all I learned from parsing through it was that when it gets into the bad state, it generates dozens of lines every second or so (which was fairly obvious already from the file size!) How would I go about "linking" to /dev/null? – JVC Sep 13 '15 at 4:33

Since symlinking doesn't work you could use a cronjob to just clear the file every now and then.

For that you will need the Terminal. If you are not familiar, here is an introduction.

Use the following command to open the crontab file (just call crontab -e if you want to use vim instead):

EDITOR=nano crontab -e

Insert the following and save the file (with Ctrl-X -> y -> enter). You must change the file to the log file

0 */1 * * * > "/Users/chaos/Library/Logs/SomeLog.log"

Let me explain: 0 */1 * * * means that on every full hour the command will be executed (unless it's turned off of course). See wikipedia for more info.

The command being executed is basically saying "redirect nothing to the file" effectively truncating it to 0 bytes. You may recognize it from echo something > somefile.log.

FYI: The cron daemon will automatically be started by launchd if a cronfile exists.

| improve this answer | |
  • If the app keeps the file open it will not be reduced in size as the cron job will not be able to write to the file (or it will create a new file and the app continue writing to the old file - which will be deleted when the app closes the file – user151019 Sep 13 '15 at 13:36
  • @Mark is exactly right, the file can't be deleted while the service is running, so unfortunately that approach is out unless it also shuts down and restarts the service before & after. Which might actually be acceptable... could run a workflow that does this at say 4am or something. I may try that. – JVC Sep 13 '15 at 18:03
  • I decided that, while my ultimate solution wasn't to use a cronjob as suggested here, it was similar enough that this question kinda deserved to win. So there ya go. =) – JVC Sep 13 '15 at 18:15
  • Thanks @JonathanvanClute It works with most log files I work with (web/application servers) so I thought it might work but it depends I guess. – 2called-chaos Sep 14 '15 at 1:41
  • Yeah it worked great - except that the Application is a little aggressive in that it creates a new one at launch even if there is a file with that name already (i.e. the alias I tried using). Still a good suggestion though so thanks! – JVC Sep 14 '15 at 15:36

If you don't actually need the content of the file, you could link it to /dev/null which means that anything written to the file will disappear immediately. To do so

  • quit the application
  • rm /path/to/logfile
  • ln -s /dev/null /path/to/logfile
| improve this answer | |
  • Aha... a simple symlink. I get it now... brilliant! Seems to be working just fine too. Thank you! – JVC Sep 13 '15 at 4:48
  • Oops, I stand corrected, it's not working at all because the service has overwritten the alias and replaced it with an actual log file as soon as it was launched. Any other suggestions? – JVC Sep 13 '15 at 4:53
  • Uhh, not nice. There is no option to define the location of the logfile in the app? Otherwise a monitoring script might be the better way but I don't have a Mac nearby to test the code currently – nohillside Sep 13 '15 at 4:56
  • Nope, no settings of any kind related to the logfile. At least not that I'm aware of... maybe there's something in some of the script code but it's beyond my abilities to comprehend thoroughly enough. Sounds like monitoring will in fact be the only real solution. =( – JVC Sep 13 '15 at 4:57

Well it turns out that while it will be somewhat tricky to actually monitor the file in question to only delete it as needed,it's trivial in Automator to simply quit the running service, delete the logfile, and re-launch the service. I can then simply execute this job every day at say 4am when nobody is likely to be watching anything from either server, and things should be good. Thanks @patrix, @2called-chaos, and @mark for ultimately all leading me to this solution.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .