--retry
keep trying to open a file even if it is inaccessible when tail
starts or if it becomes inaccessible later; useful when follow-
ing by name, i.e., with --follow=name
-F same as --follow=name --retry --retry
keep trying to open a file even if it is inaccessible when tail
starts or if it becomes inaccessible later; useful when follow-
ing by name, i.e., with --follow=name
-F same as --follow=name --retry Do not stop when end-of-file is reached, but rather to wait for
additional data to be appended to the input. If the file is re-
placed (i.e., the inode number changes), tail will reopen the
file and continue. If the file is truncated, tail will reset its
position to the beginning. This makes tail more useful for
watching log files that may get rotated. The -f option is ig-
nored if the standard input is a pipe, but not if it is a FIFO.
So, no -F or --retry but a different default behavior "For f***** sake! I should have used '-F'! Arghhh...!"
Obviously, I'm paraphrasing ;^)> FreeBSD has this
OpenBSD ≠ FreeBSD, and that's fine.
And, since we're being pedantic, when I said “vast majority of the software world”, that includes the OpenBSD project:
“Sending in bug reports
If possible, use the sendbug(1) command to get the bug into our tracking system. Sendbug requires that your system can properly send Internet email. If you cannot use sendbug on a functional OpenBSD machine, please send your bug report to bugs@openbsd.org.
Perhaps what you are sending in is a feature request, not necessarily a bug. New features are accepted, especially with code that implements your suggested new feature.”
I'm not being "pedantic", I just don't think there is anything to change.
Also, if you are using a proper ssh client, opening a second ssh connection to manage the reacting to the log files is habit for me at this point. The only time I'm using tail -F is after a new configuration deployment. Otherwise, I'm looking at archival data in ELK.
Thank you for the suggestion tho. :)