How to incorporate your ears to check log files

Today my irritation level was high enough to act. What happened?

While working on some Capybara tests, I was switching forth and back between the editor, the browser and the logfile terminal on the 2nd monitor to investigate if errors showed up in the log file.

If you ever tailed a file on a Linux system, you might have seen, that the log file is moving quite fast in your terminal window. Even on font size 6 its not easy to catch a certain ERROR label.

Opening a huge file and searching within is also not a pleasure and tedious, so that was also not an option for me.

Log-Watch

I remembered the Log-Watch tool from James Bach, which plays a sound file everytime a customizable word/phrase is found in a log file.

Alas, my work computer was not Windows based.

Would it not be nice, if there was such a tool for Macintosh?

A quick question into Slacks testers.io tool channel and Richard Bradshaw (@friendlyTester) had a solution at hand.

It basically combines the feature of the “tail” command to continously display the last entries of a given file on the screen with the “grep” command, which searches the input files for lines containing a match to a given pattern list and finally plays a sound file via afplay, if the pattern is found.

Command

tail -f <path-to-log-file> | grep --line-buffered ‘<Pattern to listen to>' | while read line; do afplay <path-to-local-sound-file>/test.wav; done

 

Richard also has a blog post up, which contains also a link into his Github repository.

Next level

That command is working locally. But the log files I use daily are on a remote server, a sandbox in my case. There are no sound files, no audio player and even it there were, its of no use, if it beeps in the server room. Might scare some admins, if it randomly beeps though.

Plus I also don’t want to install stuff on the sandbox. We delete them on a regular base and make new ones. Installing stuff would be another preparation step, which costs time.

I was wondering, if it was possible to use my local Macintosh files and hardware and started to adjust the above solution.

Command for remote files

ssh <user@remoteserver> 'tail -f <path-to-log-file>' | grep --line-buffered ‘<Pattern to listen to>' | while read line; do afplay <path-to-local-sound-file>/test.wav; done

This combined the command with the feature to log into remote machines via ssh.

 

The Benny Hill theme

Thanks to @simonk the tool channel probably had an earworm for the rest of the day, cause he brought up the Benny Hill theme.

Anyone not familiar, click on play here.

 

Lessons Learned for me

First, we are a global, intensively knowledgable community. As so often in development, someone somewhere might had the same obstacle and can help you out. Or s/he has the right skills to solve your problem. This was an exercise in tester pairing btw.

So reach out and connect. It can only be a win win situation.

 

Second, if something troubles / irritates you enough, it might be worth to investigate and automate it.

Yes, it can be called automation. We created a small line of code to help us in our testing work.

 

Third, remember that we have more senses in our portfolio than “just” our eyes, to watch what the software is doing.

The blink heuristic relies on your visual sense as well.

While smell has become a little out of fashion, even that was used before (Smoke Test anyone?).

If you are in mobile testing, the tactile sense is useful, e.g. when your battery becomes warmer, than you expect.

 

Conclusion

I used this command the whole afternoon, while testing and listening to music.

Believe me, the sound file you choose will be heard, even with music on, cause it is also a kind of blink heuristic for your ears. It sticks out.

This will give you an additional layer of information in your testing, because you can now make use of two senses instead of one.

The whole “development” might have taken maybe like 30 minutes and I am quite sure, it already has paid off.

 

2 thoughts on “How to incorporate your ears to check log files”

  1. Pingback: Reading Recommendations # 23 | Adventures in QA

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.