Если приложение, запущенное через &, попробует написать что-то в консоль, то при невозможности написать в эту консоль начнутся проблемы (приложение словит SIGHUP или SIGPIPE). Решение - перенаправить явно весь вывод в /dev/null:
command > /dev/null 2> /dev/null &
Вместо двух перенаправлений в /dev/null можно одно перенаправление в /dev/null и одно в другой:
command > /dev/null 2>&1 &
Так делать в подобной ситуации необязательно, но часто делают, и полезно знать. Также надо понимать, что запись:
> file
эквивалентна:
>1 file
А запись:
< file
эквивалентна:
<0 file
Всё потому, что стандартные файловые идентификаторы такие: 0 - stdin, 1 - stdout, 2 - stderr.
Также бывают проблемы, когда приложение хочет что-то прочитать с консоли. Можно ему и на вход передать тоже /dev/null:
command > /dev/null 2> /dev/null < /dev/null &
Но даже в таком случае при закрытии консоли bash пошлёт висящему в фоне процессу SIGHUP. Чтобы это не случилось, нужно сделать disown сразу после выполнения команды, и это можно сделать в той же строке:
command > /dev/null 2> /dev/null < /dev/null & disown
Всё это можно сделать одной командой nohup, которая упрощает все эти действия и вывод записывет в файл nohup.out:
nohup command &
Подробнее в man, он довольно короткий и рассказывает всё в деталях.
Иногда приложения не могут работать совсем без терминала, в этом случае их можно запускать в в screen/tmux или docker.
Я не просто так рассказываю: понимать теорию очень полезно, в том числе теперь, надеюсь, не возникнет вопроса, почему длительные и просто даже критические к прерыванию операции настоятельно советуют запускать в screen, а не полагаться на то, что они успешно завершатся без отваливания консоли, и добавление & тут ничего не гарантирует!
Но всё же, совет сразу же научиться использовать systemd (а в других операционных системах и дистрибутивах - возможно свои другие системы управления сервисами) - он ОЧЕНЬ ПРАВИЛЬНЫЙ. Это сложно только в первый раз :)
Также в особых случаях можно ограничиться специализированными менеджерами типа supervisor или pm2. Особыми являются только случаи, когда подобные менеджеры уже используются для запуска других сервисов, с нуля их использовать при наличии универсального и хорошо работающего systemd практически лишено смысла.
