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

From: Azat Khuzhin <[email-masked]>
Date: Tue, 27 May 2014 01:00:22 +0400

On Mon, May 26, 2014 at 09:43:23PM +0100, Pádraig Brady wrote:
> 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,

Hm, didn't know that, Thanks!
(Sometimes POSIX is not so good for human, I suppose.)

> 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

Yes this is the same as I linked above.
Does any body have a patch for this, or should I start working on this?

Thanks.

> thanks,
> Pádraig.

-- 
Respectfully
Azat Khuzhin