Your message dated Fri, 9 Aug 2019 13:08:01 +0200
with message-id <20190809110801.fhr3pjvvqr45c...@sym.noone.org>
and subject line Re: Bug#934301: ack searches the output file creating a loop
has caused the Debian Bug report #934301,
regarding ack searches the output file creating a loop
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
934301: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934301
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: ack
Version: 2.24-1
Severity: critical
Justification: causes serious data loss
Dear Maintainer,
* What led up to the situation?
Searching a string in a folder with only a single file in it.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I've run "ack Time > time.txt" in a folder that had only one file
in it (8MB mysql-slow.log.1 to be exact).
* What was the outcome of this action?
time.txt file ended up being 14GB in size, filling the disk to 100%
and crashing the database.
* What outcome did you expect instead?
A similar outcome with "ack Time mysql-slow.log.1 > time.txt" which
results in an output 135KB file.
* To recreate the problem the file that is being searched needs to be
big enough, the string that is being searched needs to be scarce
enough and the output filename should not contain the searched
string. I can provide the file if needed.
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ack depends on:
ii libfile-next-perl 1.16-2
ii perl 5.28.1-6
ack recommends no packages.
ack suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Dear Ali,
ali wrote:
> Severity: critical
> Justification: causes serious data loss
I don't see any data _loss_ in your bug description. A full disk
always causes trouble, but blaming any tool used together with output
redirection for this is rather far fetched.
And even if so, searching a directory and then saving the result in
the same directory is against common sense as it _obviously_ causes an
endless loop. That's about the same as "grep foo bar >> bar".
> time.txt file ended up being 14GB in size, filling the disk to 100%
I'm sorry, but I can't reproduce this:
/tmp/ack-#934301 → ls -lha
total 13M
drwxr-xr-x 2 abe abe 4.0K Aug 9 12:40 ./
drwxrwxrwt 20 root root 20K Aug 9 12:35 ../
-rw-r--r-- 1 abe abe 13M Aug 9 12:35 aptitude-robot.log
/tmp/ack-#934301 → ack abe-desktop > foo
/tmp/ack-#934301 → ls -lha
total 13M
drwxr-xr-x 2 abe abe 4.0K Aug 9 12:40 ./
drwxrwxrwt 20 root root 20K Aug 9 12:35 ../
-rw-r--r-- 1 abe abe 13M Aug 9 12:35 aptitude-robot.log
-rw-r--r-- 1 abe abe 6.2K Aug 9 12:40 foo
/tmp/ack-#934301 →
> and crashing the database.
Which database? You mean the mysql database that log you searched in
is from?
> * To recreate the problem the file that is being searched needs to be
> big enough, the string that is being searched needs to be scarce
> enough and the output filename should not contain the searched
> string. I can provide the file if needed.
I can neither reproduce this with the 16 MB file in the example above
(where the ack exits more or less instantaneously) nor with 5 GB log
file where ack takes about 15 seconds to search through. (JFTR: I
always used a tmpfs as file system for these tests.)
I though can reproduce this issue if and _only_ if the output log file
already exists (you claimed the directory was empty initially) _and_
if I append to it instead of overwriting it. (But all your examples
just show a single ">", no double ">>" for appending.)
And even if the same thing can also be achieved with just ">" instead
of ">>" on _really_ slow file system where the shell (and not ack)
creates the output file before ack has found all files in the
directory, this is no bug:
Searching the same file (or directory) your appending (or generally
outputting) to is about the same as taking a gun, pointing it
downwards to your feet and pulling the trigger — but definitely no
issue of the gun.
Hence closing this bug report.
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
--- End Message ---
