Find errors across Linux logs with grep: Case, filenames, and line numbers

The log clearly contains ERROR, yet grep error prints nothing. The event probably did not disappear: the search might be looking at the wrong files or using the wrong letter case. Check the search target before inferring that no error occurred.

What does grep search in a log?

grep 'error' app.log prints lines in app.log matching the pattern. Unlike cat, it does not display the whole file; unlike tail, it is not limited to the end.

By default, grep distinguishes error from ERROR. And a command naming only app.log never reads worker.log. “No result” means only that the given pattern did not match in the files actually searched.

How do you find error and ERROR in two logs?

Make two small files in a temporary directory. The times and events are illustrative:

demo_dir=$(mktemp -d)
printf '%s\n' \
  '09:00 INFO boot' \
  '09:01 WARN retry' \
  '09:02 ERROR db timeout' \
  '09:03 INFO recovered' > "$demo_dir/app.log"
printf '%s\n' \
  '09:00 INFO started' \
  '09:04 error cache miss' \
  '09:05 INFO ready' > "$demo_dir/worker.log"
cd "$demo_dir"
grep -nH 'error' ./*.log

./worker.log:2:09:04 error cache miss

The uppercase entry in app.log was missed. Add -i to ignore case:

grep -inH 'error' ./*.log

./app.log:3:09:02 ERROR db timeout
./worker.log:2:09:04 error cache miss

The prefix is filename:line number:content. -i ignores case, -n shows line numbers, and -H always shows filenames. ./*.log is expanded by the shell to files in the current directory; it does not automatically search subdirectories. The GNU grep manual documents these flags and output conventions.

The diagram excerpts the matching filename, line number, and term. The command output above includes the full matching lines.

Can one matching line explain the incident?

ERROR db timeout alone does not reveal the earlier retry or later recovery. Use -C 1 for one line of context before and after:

grep -inH -C 1 'error' ./app.log

./app.log-2-09:01 WARN retry
./app.log:3:09:02 ERROR db timeout
./app.log-4-09:03 INFO recovered

The matching line uses : separators; context lines use -. These three lines still do not establish the root cause. Use less app.log if you need wider context.

If logs live under subdirectories, choose that scope deliberately, for example grep -rinH 'error' "$demo_dir". Avoid searching all of /var/log by habit when unrelated files and permission errors would obscure the signal.

What does an empty result mean?

grep prints nothing if it finds no matching line. Check its exit status immediately:

grep -n 'fatal' ./app.log
echo $?

1

Here 1 means no matching line in the file that was read. It differs from a file-reading error. Run echo $? immediately, because another command replaces the last exit status. The GNU grep exit-status guide distinguishes a match, no match, and an error.

When output is empty, check the current directory and filenames, letter case, and whether the search covered the relevant time or directory. Only then say that the searched file contains no match.

Key takeaways

grep selects matching lines from specified files. For multiple logs, choose ./*.log, use -i for case-insensitive matching and -nH for line numbers and filenames. Add -C 1 for context, and verify the searched scope before treating no output as no incident.