summaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorBernhard Voelker <mail@bernhard-voelker.de>2013-04-20 16:33:06 +0200
committerBernhard Voelker <mail@bernhard-voelker.de>2013-04-20 16:33:06 +0200
commitd461bfd2743547360793acd2118d4c08ad7b84a8 (patch)
tree6e81dc004be45e9dea0c7b469b7d98c9f0277950 /src
parent1dd8a33169b69716c4a4b92dbe1bd99336d92b23 (diff)
downloadcoreutils-d461bfd2743547360793acd2118d4c08ad7b84a8.tar.xz
tail: let -f --retry wait for inaccessible files
The --retry option is indeed useful for both following modes by name and by file descriptor. The difference is that in the latter case, it is effective only during the initial open. As a regression of the implementation of the inotify support, tail -f --retry would immediately exit if the given file is inaccessible. * src/tail.c (usage): Change the description of the --retry option: remove the note that this option would mainly be useful when following by name. (main): Change diagnosing dubios uses of --retry option: when the --retry option is used without following, then issue a warning that this option is ignored; when it is used together with --follow=descriptor, then issue a warning that it is only effective for the initial open. Disable inotify also in the case when the initial open in tail_file() failed (which is the actual bug fix). * init.cfg (retry_delay_): Pass excess arguments to the test function. * tests/tail-2/retry.sh: Add new tests. * tests/local.mk (all_tests): Mention it. * doc/coreutils.texi (tail invocation): Enhance the documentation of the --retry option. Clarify the difference in tail's behavior regarding the --retry option when combined with the following modes name versus descriptor. * NEWS (Bug fixes): Mention the fix. Reported by Noel Morrison in: http://lists.gnu.org/archive/html/coreutils/2013-04/msg00003.html
Diffstat (limited to 'src')
-rw-r--r--src/tail.c21
1 files changed, 15 insertions, 6 deletions
diff --git a/src/tail.c b/src/tail.c
index cdaecddc4..373575705 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -294,9 +294,7 @@ With no FILE, or when FILE is -, read standard input.\n\
fputs (_("\
--pid=PID with -f, terminate after process ID, PID dies\n\
-q, --quiet, --silent never output headers giving file names\n\
- --retry keep trying to open a file even when it is or\n\
- becomes inaccessible; useful when following by\n\
- name, i.e., with --follow=name\n\
+ --retry keep trying to open a file if it is inaccessible\n\
"), stdout);
fputs (_("\
-s, --sleep-interval=N with -f, sleep for approximately N seconds\n\
@@ -2030,8 +2028,14 @@ parse_options (int argc, char **argv,
}
}
- if (reopen_inaccessible_files && follow_mode != Follow_name)
- error (0, 0, _("warning: --retry is useful mainly when following by name"));
+ if (reopen_inaccessible_files)
+ {
+ if (!forever)
+ error (0, 0, _("warning: --retry ignored; --retry is useful"
+ " only when following"));
+ else if (follow_mode == Follow_descriptor)
+ error (0, 0, _("warning: --retry only effective for the initial open"));
+ }
if (pid && !forever)
error (0, 0,
@@ -2182,6 +2186,10 @@ main (int argc, char **argv)
in this case because it would miss any updates to the file
that were not initiated from the local system.
+ ok is false when one of the files specified could not be opened for
+ reading. In this case and when following by descriptor,
+ tail_forever_inotify() cannot be used (in its current implementation).
+
FIXME: inotify doesn't give any notification when a new
(remote) file or directory is mounted on top a watched file.
When follow_mode == Follow_name we would ideally like to detect that.
@@ -2193,7 +2201,8 @@ main (int argc, char **argv)
is recreated, then we don't recheck any new file when
follow_mode == Follow_name */
if (!disable_inotify && (tailable_stdin (F, n_files)
- || any_remote_file (F, n_files)))
+ || any_remote_file (F, n_files)
+ || (!ok && follow_mode == Follow_descriptor)))
disable_inotify = true;
if (!disable_inotify)