i am running videos on raspberryPi+bigMonitor few meters from me with command:

ssh    pi 'omxplayer file.mp4 </dev/null &>/dev/null &'

that works great.

But if i want to use ssh's virtual terminal allocation -t that command do not works anymore.

I really need -t for using great ncurses based video menu with 'fzf' before omxplayer, but all of my specific problems are not important, because main problem can be simulated with sleep 10 instead of omxplayer:

on remote computer:

watch -n1 'ps aux | grep [s]leep\ 10'   #monitoring if 'sleep' running.

on local computer various tests:

ssh -t pi 'sleep 10 </dev/null &>/dev/null &'                  #not working
ssh -t pi 'nohup  sleep 10 </dev/null &>/dev/null & disown'    #not working
ssh -t pi 'setsid sleep 10 </dev/null &>/dev/null &'           #not working
ssh -t pi 'nohup  sleep 10 </dev/null &>/dev/null & sleep 0'   #works OK !!!!
ssh -t pi 'setsid sleep 10 </dev/null &>/dev/null & sleep 0'   #works OK
ssh -t pi 'nohup  sleep 10 </dev/null &>/dev/null & /bin/true' #not working
ssh -t pi 'nohup  sleep 10 </dev/null &>/dev/null & (true & wait)' #works ok

'sleep 0' in the end is probably the best solution, proposed by @egmont.

Still wondering if there is some better, more reliable solution, and what was exact cause for this (probably ssh closing vt is too fast for parallel nohup/setsid run).

  • I see from your edits that you have already considered tmux or screen. What is the relation between fzf and your problem?
    – icarus
    Nov 28, 2016 at 17:05
  • @icarus this commands are simplified situation of real scripts where i reached this problem, and where i used fzf. fzf over ssh needs virtual terminal 'ssh -t', and this problem will reach anyone who for some reason uses '-t' and have no commands after detaching. Nov 28, 2016 at 17:17
  • 1
    The discussion at bugs.launchpad.net/ubuntu/+source/systemd/+bug/1429938 perhaps gives you some clues. I'm not sure if ssh cares whether the child process it launched finishes, but it definitely cares about the 3 standard file descriptors still being open or getting closed. If you just execute a single command then bash optimizes it to be an "exec", closing its 3 standard FDs and then replacing itself with omxplayer or nohup, which might be too late. If you have that "sleep" then bash cannot do this optimization, hence it'll close its FDs only after executing omxplayer or nohup...
    – egmont
    Nov 28, 2016 at 17:26
  • 1
    ... so try replacing that "sleep 0.1" with "sleep 0" or "/bin/true", my guess is that it'll also work.
    – egmont
    Nov 28, 2016 at 17:26
  • @egmont 'sleep 0' cool idea, tested now, it works :) ... /bin/true will be beter but it not works, simple 'ls' works too, and '(true & wait) works too. comparing to c programming, command must wait for something (allowing other thread execution)... but sleep 0 seems the best for now. Nov 28, 2016 at 17:35

1 Answer 1


The issue appears to be that the background shell that will turn into nohup to run sleep or omxplayer is getting a SIGHUP before it has turned into nohup and set the signal handler to ignore.

ssh -t pi 'trap HUP "" ; omxplayer file.mp4 </dev/null &>/dev/null &'

works for me every time, whilst some of the other approaches like sleep 0 sometimes fail.

  • respect, you solve it the best way. btw "" before hup, working well in my scripts. Nov 29, 2016 at 2:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .