0

I think this sums it up:

# /usr/bin/nohup echo hello
/usr/bin/nohup: ignoring input and appending output to `nohup.out'

# ssh localhost /usr/bin/nohup echo hello
hello

What was happened?

cuonglm
  • 153,898
samwyse
  • 117

2 Answers2

5

Apparently,

recent versions of ssh started using pipes for non-TTY STDIO

so

there is no way for a bash script to tell whether a non-tty ssh command is being piped or not.

Since nohup only springs into action when it detects that stdout/stderr are connected to a terminal (and does nothing when the output goes to a pipe), and ssh's way of launching it looks like it's being piped, you get the behaviour you're seeing.

As muru points out, you can force ssh to allocate a tty by using the -t parameter:

$ ssh -t localhost "/usr/bin/nohup /bin/echo foo"
/usr/bin/nohup: ignoring input and appending output to ‘nohup.out’
Community
  • 1
n.st
  • 8,128
3

From man nohup (POSIX):

   If  the  standard output is a terminal, all output written by the named
   utility to its standard output shall be appended to the end of the file
   nohup.out  in  the current directory. ...

   If the standard error is a terminal, all output written  by  the  named
   utility  to  its  standard  error  shall be redirected to the same file
   descriptor as the standard output.

To stress: If the standard output is a terminal.

With a simple ssh nohup echo foo, standard output isn't a TTY unless you tell SSH to create one:

ssh -t localhost nohup echo foo

From man ssh:

-T   Disable pseudo-tty allocation.
-t   Force pseudo-tty allocation.  This can be used to execute
     arbitrary screen-based programs on a remote machine, which can be
     very useful, e.g. when implementing menu services.  Multiple -t
     options force tty allocation, even if ssh has no local tty.

Also see:

Community
  • 1
muru
  • 72,889
  • Someone give this human an upvote. No idea why you were downvoted in the first place… – n.st Oct 20 '16 at 14:28
  • @n.st Probably because my original answer was a bit short. It happens. :D – muru Oct 20 '16 at 14:28
  • Explanation is incomplete: ssh me@remote echo "Hello" > /home/me/somefile creates the file alright, while nohup cannot create the file . This is what needs to be added to your explanation. – MariusMatutiae Oct 20 '16 at 14:38
  • 1
    @MariusMatutiae nonsense. That file will be created irrespective of whether you use ssh ... nohup, since it is your local shell that's doing the redirection and creation of that file. – muru Oct 20 '16 at 14:40
  • You just quoted text saying that nohup is not invoked when the output file cannot be created... You are contradicting yourself (and only Walt Whitman is allowed to do that). – MariusMatutiae Oct 20 '16 at 14:42
  • 1
    @MariusMatutiae that's for nohup creating its own output file. (nohup saves output in a file.) nohup neither knows nor cares about what your local shell is doing, until you tell SSH to allocate a TTY. Even then, if your local shell cannot create the file, it will not start the command, so it's not nohup that fails. – muru Oct 20 '16 at 14:45