1

I have a log file that text is appended to during the program run. I want to know when a specific string was appended to the end of the file.

All the solutions given here: Monitoring a file until a string is found and here: https://stackoverflow.com/questions/25959870/how-to-wait-till-a-particular-line-appears-in-a-file work, but only on Ubuntu.

I'm trying to do the same thing on Centos 7 and it doesn't seem to end the command.

some things I tried that work in Ubuntu but not in Centos 7:

( tail -f -n0 logfile & ) | grep -q "database start"

tail -n0 -f logfile  | sed '/database start/ q'

No idea why it would not work on CentOS 7 but on Ubuntu it does work. I prefer to use a single command instead of sleeping x and grep again, because the line should be outputted multiple times in the file and I want only the one since I started checking the file

I did check the log file and the line did appear, but none of the commands stopped.

DavidPostill
  • 153,128
  • 77
  • 353
  • 394
Codo
  • 13
  • 3
  • Related? [*Why isn't `tail -f … | grep -q …` quitting when it finds a match?*](https://superuser.com/q/1404982/432690) Still, even if `tail` is not patched, I expect the command that runs it in the background (i.e. the one with `( tail … & )`) to kinda work; so there must be something else. – Kamil Maciorowski Feb 28 '23 at 17:30
  • Test with `logfile` that is under your total control. Use `echo foo >> logfile` and `echo "database start" >> logfile` while `tail` runs. Do the commands in question fail to do their job in these circumstances? – Kamil Maciorowski Feb 28 '23 at 17:45
  • seems to detect >> but not >, any way to also detect > ? – Codo Mar 01 '23 at 09:19
  • (1) Why do you want `>`? Usually for logfiles `>>` is better. If more than one process writes then `>>` is definitely better (see [this question](https://superuser.com/q/1342489/432690)). (2) Anyway, for me it works also with `>` but `tail` exits when the file is truncated, it may be not what you want. Don't use `>` then. The only case where it "doesn't work" is if the file contains `database start` as a sole line already acknowledged by `tail` (but not printed due to `-n0`); executing `echo "database start" > logfile` brings the file to the same state; `tail` cannot notice (cont'd) – Kamil Maciorowski Mar 01 '23 at 11:38
  • (cont'd) unless it gets scheduled exactly between truncating and writing, this is unlikely. (3) Sanity check: you say "it doesn't seem to end the command" in your original question. Please investigate if it detects the matching line in the first place (run `grep` without `-q` and see if it prints). Maybe the problem is not in "doesn't end", maybe the problem is in "doesn't see". How exactly did you "check the log file and the line did appear"? Was the file removed and created anew? Maybe you need `tail -F`. – Kamil Maciorowski Mar 01 '23 at 11:42

1 Answers1

0

Is it possible the "database start" is perhaps written as "Database start"?
The default grep may not ignore a change of case, requiring grep -i for doing that.

The following might be safer syntax :

grep -q "database start" <(tail -f logfile)

Reference : How to wait till a particular line appears in a file.

harrymc
  • 455,459
  • 31
  • 526
  • 924
  • This is not the case, I put databse start just as an example, but there is no problem there. – Codo Feb 28 '23 at 17:35
  • Noted. Is the above syntax working better on CentOS? – harrymc Feb 28 '23 at 17:36
  • Which shell are you using? – harrymc Mar 01 '23 at 09:16
  • It doesn't work. fixed the spaces. I use bash. – Codo Mar 01 '23 at 09:18
  • Just tested it - the error is in the blank after the redirection. See my correction above. – harrymc Mar 01 '23 at 09:22
  • Ok I just tested it and seems to work. However, it works only once. and if I use the same command later it justs exits right away, so It greps the whole file? like I said, The line can appear multiple times, I want to read the output from the moment I started the command – Codo Mar 01 '23 at 13:10
  • Tail will by default only print the last 10 lines. If 10 is too much, you can reduce it with the `-n` parameter, for example `(tail -f -n1 logfile)` for only one last line. – harrymc Mar 01 '23 at 14:48
  • Great, this solution works :) – Codo Mar 01 '23 at 15:05