Asynchronous shell command that leaves a background process running

Asynchronous shell command that leaves a background process running

[Sean McAfee]

I've written a shell script which is essentially a single exec command:

  #!/bin/bash
  exec real-program fixedarg1 fixedarg2 "$@"

"real-program" chugs along for several seconds, printing some status
messages in the meantime, before finally forking off a background
process and exiting.  The background process manifests a window on my
desktop.

All is well when I run this command from an interactive shell, but
things fall apart when I try to run it as an asynchronous shell command
from Emacs, a la:

  (shell-command "wrapper-script arg1 arg2 &")

I see the status messages appear in the *Async Shell Command* buffer,
but when the command exits, no desktop window appears.

The only fix I've found is to execute real-program in a separate process
group:

  #!/bin/bash
  perl -e 'if (fork() == 0) { setpgrp; exec @ARGV } wait' \
    real-program fixedarg1 fixedarg2 "$@"

I guess Emacs is sending a fatal signal (probably SIGHUP) to the
asynchronous shell's process group after the main process exits.

Naturally I don't want to have to write my scripts defensively against
the possibility of running asynchronously from Emacs.  So I can just
move my perl/setpgrp wrapper inside Emacs:

  (shell-command "perl -e 'if (fork() == 0) { setpgrp; exec @ARGV } wait' wrapper-script arg1 arg2 &")

That's pretty ugly, though.  A little Googling turned up the nohup
command, which also mostly does the job:

  (shell-command "nohup wrapper-script arg1 arg2 | cat &")

The "| cat" is necessary to prevent nohup from redirecting output to
nohup.out.  That's still ugly, and I also get the distracting header
"nohup: ignoring input and redirecting stderr to stdout" prepended to my
normal output.

Is there a more elegant way to address this problem?

Re: Asynchronous shell command that leaves a background process running

[Andreas Politz]

Sean McAfee <eefacm@gmail.com> writes:

> I've written a shell script which is essentially a single exec command:
>
>   #!/bin/bash
>   exec real-program fixedarg1 fixedarg2 "$@"
>
> "real-program" chugs along for several seconds, printing some status
> messages in the meantime, before finally forking off a background
> process and exiting.  The background process manifests a window on my
> desktop.
>
> All is well when I run this command from an interactive shell, but
> things fall apart when I try to run it as an asynchronous shell command
> from Emacs, a la:
>
>   (shell-command "wrapper-script arg1 arg2 &")
>
> I see the status messages appear in the *Async Shell Command* buffer,
> but when the command exits, no desktop window appears.
>
> The only fix I've found is to execute real-program in a separate process
> group:
>
>   #!/bin/bash
>   perl -e 'if (fork() == 0) { setpgrp; exec @ARGV } wait' \
>     real-program fixedarg1 fixedarg2 "$@"
>
> I guess Emacs is sending a fatal signal (probably SIGHUP) to the
> asynchronous shell's process group after the main process exits.
>
> Naturally I don't want to have to write my scripts defensively against
> the possibility of running asynchronously from Emacs.  So I can just
> move my perl/setpgrp wrapper inside Emacs:
>
>   (shell-command "perl -e 'if (fork() == 0) { setpgrp; exec @ARGV } wait' wrapper-script arg1 arg2 &")
>
> That's pretty ugly, though.  A little Googling turned up the nohup
> command, which also mostly does the job:
>
>   (shell-command "nohup wrapper-script arg1 arg2 | cat &")
>
> The "| cat" is necessary to prevent nohup from redirecting output to
> nohup.out.  That's still ugly, and I also get the distracting header
> "nohup: ignoring input and redirecting stderr to stdout" prepended to my
> normal output.
>
> Is there a more elegant way to address this problem?

Try this.

(let ((process-connection-type nil))  ; Use a pipe instead of pty
      (shell-command "foo bar blub &"))

I think what we are talking about are `orphaned children', whose session
leader died and who are automatically sent a SIGHUP as part of libc (not
Emacs).

-ap

Re: Asynchronous shell command that leaves a background process running

[Pascal J. Bourguignon]

Sean McAfee <eefacm@gmail.com> writes:

> I've written a shell script which is essentially a single exec command:
>
>   #!/bin/bash
>   exec real-program fixedarg1 fixedarg2 "$@"
>
> "real-program" chugs along for several seconds, printing some status
> messages in the meantime, before finally forking off a background
> process and exiting.  The background process manifests a window on my
> desktop.
>
> All is well when I run this command from an interactive shell, but
> things fall apart when I try to run it as an asynchronous shell command
> from Emacs, a la:
>
>   (shell-command "wrapper-script arg1 arg2 &")
> [...]
> Is there a more elegant way to address this problem?

You can use:

  (shell-command "wrapper-script arg1 arg2 & disown")


But really, the problem is with your real-program, which should be doing
the same as disown (setting a new process group, etc), since it exits
before its children.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: Asynchronous shell command that leaves a background process running

[Sean McAfee]

Andreas Politz <politza@fh-trier.de> writes:
> Sean McAfee <eefacm@gmail.com> writes:
>>   (shell-command "nohup wrapper-script arg1 arg2 | cat &")
[...]
>> Is there a more elegant way to address this problem?

> Try this.
>
> (let ((process-connection-type nil))  ; Use a pipe instead of pty
>       (shell-command "foo bar blub &"))

Nice!  Thanks.  Shortly after posting my original article, I factored
out the new-process-group logic into a short wrapper program, so I could
just say:

  (shell-command "in-a-new-process-group wrapper-script arg1 arg2 &")

That was nicer than anything I'd yet come up with, but your solution is
even better.

Re: Asynchronous shell command that leaves a background process running

[Andreas Politz]

Sean McAfee <eefacm@gmail.com> writes:

> Andreas Politz <politza@fh-trier.de> writes:
>> Sean McAfee <eefacm@gmail.com> writes:
>>>   (shell-command "nohup wrapper-script arg1 arg2 | cat &")
> [...]
>>> Is there a more elegant way to address this problem?
>
>> Try this.
>>
>> (let ((process-connection-type nil))  ; Use a pipe instead of pty
>>       (shell-command "foo bar blub &"))
>
> Nice!  Thanks.  Shortly after posting my original article, I factored
> out the new-process-group logic into a short wrapper program, so I could
> just say:
>
>   (shell-command "in-a-new-process-group wrapper-script arg1 arg2 &")
>
> That was nicer than anything I'd yet come up with, but your solution is
> even better.

I think Pascals point is still valid: Why can't your script wait for
it's children to die ? 

-ap

Re: Asynchronous shell command that leaves a background process running

[Sean McAfee]

pjb@informatimago.com (Pascal J. Bourguignon) writes:
> Sean McAfee <eefacm@gmail.com> writes:
>> All is well when I run this command from an interactive shell, but
>> things fall apart when I try to run it as an asynchronous shell command
>> from Emacs, a la:
>>
>>   (shell-command "wrapper-script arg1 arg2 &")
>> [...]
>> Is there a more elegant way to address this problem?

> You can use:
>
>   (shell-command "wrapper-script arg1 arg2 & disown")

I tried variations on that, but couldn't find any way to run
wrapper-script asynchronously, receiving its status messages in Emacs as
it runs.

> But really, the problem is with your real-program, which should be doing
> the same as disown (setting a new process group, etc), since it exits
> before its children.

That's problematic, since real-program is a Java program.

Re: Asynchronous shell command that leaves a background process running

[Sean McAfee]

Andreas Politz <politza@fh-trier.de> writes:
> Sean McAfee <eefacm@gmail.com> writes:
>> Andreas Politz <politza@fh-trier.de> writes:
>>> Try this.
>>>
>>> (let ((process-connection-type nil))  ; Use a pipe instead of pty
>>>       (shell-command "foo bar blub &"))

>> Nice!  Thanks.

> I think Pascals point is still valid: Why can't your script wait for
> it's children to die ? 

Well, because one of the children is a window-manifesting program that
might persist for many hours.

More specifically, what I've been calling "real-program" is a Java
program that interacts with an intranet web server, downloads a JNLP
file, and invokes Java Web Start on that file.