help-bash
[Top][All Lists]
Advanced

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

Re: [Help-bash] Command Substition (using tail) in exec line stopped wor


From: Erik Ackermann
Subject: Re: [Help-bash] Command Substition (using tail) in exec line stopped working
Date: Fri, 14 Oct 2016 15:04:08 -0700

A simple workaround is just to use nohup in the process substitution:

  exec ./script.sh >(nohup tail > log)

I think I understand now why this fails with exec. IIUC, >(tail >log)
creates a child process of the current shell. However when using exec, it
now becomes a child process of script.sh. When script.sh exits, the kernel
sends SIGHUP to all child processes.

I could probably rework my real usecase to make >(tail) be a child of the
next parent, but the nohup workaround is probably much cleaner. Still not
sure why this worked before.. maybe the kernel is much faster about
SIGHUPing in a recent version or something.

On Fri, Oct 14, 2016 at 2:51 PM, Erik Ackermann <address@hidden
> wrote:

> Firstly, I should have titled "Process substitution" not command
> substitution.
>
> So I used strace to attach to the substituted process, and it just seems
> like both `head` and `tail` are killed before they write out, but cat is
> much faster.
>
> Here is a trace of "head -n1" which is killed faster than it can write, if
> I add a sleep or block to script.sh it completes fine:
>
> sudo strace -r -p 60210
> Process 60210 attached
>      0.000000 read(0, "SUCCESS\n", 8192) = 8
>      1.641432 lseek(0, 0, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
>      0.000126 fstat(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
>      0.000136 --- SIGHUP {si_signo=SIGHUP, si_code=SI_KERNEL} ---
>      0.000170 +++ killed by SIGHUP +++
>
> Why is the substituted process killed with SIGHUP.. why don't we just
> close the FD and let the process continue to run? Was this behavior
> changed?  I'm pretty sure this used to be the behavior at some point, will
> try to dig up an old bash.
>
> On Fri, Oct 14, 2016 at 11:35 AM, Erik Ackermann <
> address@hidden> wrote:
>
>> So I just posted a more detailed, formatted version on stackexchange, but
>> wanted to reach out here as well, particularly since this might be a
>> regression, or at least a new behavior I was not aware of.
>>
>> http://unix.stackexchange.com/questions/316479/bash-command-
>> substitution-in-exec-line-some-commands-stopped-working
>>
>> Basically though, this command works (script.sh writes to /tmp/log):
>>
>>   exec ./script.sh >(cat > log)
>>
>> While this one does not work (file created but no contents):
>>
>>   exec ./script.sh >(tail > log)
>>
>> Where script.sh contains:
>>
>>   #!/bin/bash
>>   echo "fd: $1" >/tmp/out
>>   ls -l "$1" >>/tmp/out
>>   echo "SUCCESS" > "$1"
>>
>> In both cases /tmp/out shows a writable fd.
>>
>> It's a boiled down example of something that's been in my .bashrc for a
>> long time, but just noticed it stopped working on my machine recently. Is
>> there something special about the tail/head commands that makes this not
>> work..?
>>
>> Bash version: GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
>>
>
>


reply via email to

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