Estou executando vídeos no raspberryPi + bigMonitor a poucos metros de mim com o comando:
ssh pi 'omxplayer file.mp4 </dev/null &>/dev/null &'
isso funciona muito bem.
Mas se eu quiser usar a alocação de terminal virtual do ssh -t , esse comando não funciona mais.
Eu realmente preciso de -t para usar o menu de vídeo baseado em ncurses com 'fzf' antes do omxplayer, mas todos os meus problemas específicos não são importantes, porque o problema principal pode ser simulado com sleep 10 em vez de omxplayer:
no computador remoto:
watch -n1 'ps aux | grep [s]leep\ 10' #monitoring if 'sleep' running.
no computador local, vários testes:
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' no final é provavelmente a melhor solução, proposta por @egmont.
Ainda está se perguntando se existe alguma solução melhor e mais confiável, e qual foi a causa exata disso (provavelmente o fechamento ssh vt é muito rápido para execução paralela de nohup / setsid).
O problema parece ser que o shell em segundo plano que irá se transformar em nohup para executar o sleep ou o omxplayer está recebendo um SIGHUP antes que ele se transforme em nohup e configure o manipulador de sinal para ignorar.
ssh -t pi 'trap HUP "" ; omxplayer file.mp4 </dev/null &>/dev/null &'
funciona para mim todas as vezes, enquanto algumas das outras abordagens como sleep 0 às vezes falham.