bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14752: [PATCH] sort: print warning when fork() failed for --compress


From: Pádraig Brady
Subject: bug#14752: [PATCH] sort: print warning when fork() failed for --compress-program
Date: Mon, 26 May 2014 21:48:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 05/26/2014 09:13 PM, Azat Khuzhin wrote:
> sort already have one when it trying to create decompressor, it is
> obvious why it is really required in this case, since sort will read
> compressed data as plain otherwise.
> But sometimes it is really usefull to know whether sort failed to create
> compressor or not, since some users may rely on available free space and
> compressor.
> 
> * src/sort.c (create_temp_file): Add a warning when creating of
> compressor failed.
> ---
> There is some old discussion about this
> http://osdir.com/ml/bug-coreutils-gnu/2013-07/msg00010.html, but before this
> will be fixed(?) we could print a warning on fail at least.
> Thanks.
> 
>  src/sort.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/src/sort.c b/src/sort.c
> index 49caae5..eb1b1f3 100644
> --- a/src/sort.c
> +++ b/src/sort.c
> @@ -1133,6 +1133,13 @@ maybe_create_temp (FILE **pfp, bool 
> survive_fd_exhaustion)
>  
>            async_safe_die (errno, "couldn't execute compress program");
>          }
> +      else
> +        {
> +          error (0, errno,
> +                 _("warning: couldn't create process for %s "
> +                   "(try to install overcommit always)"),
> +                 compress_program);
> +        }
>      }
>  
>    *pfp = fdopen (tempfd, "w");

Thanks for the patch.

Note POSIX says that programs shouldn't output to stderr
unless they're exiting with a failure code,
I guess to avoid gradual accretion of warnings etc.
which could impair general usage.

So the issue here is that sort is allocating
a large buffer up front thus impacting the fork().
Really sort(1) should be trying to avoid this issue
in the first place, and the issue is already logged at:
http://bugs.gnu.org/14752

thanks,
Pádraig.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]