Which THREE approaches keep a long-running command alive after you disconnect an SSH session?
LPIC-1 Exam 101-500, objective 103. GNU and Unix commands hard
Draft — not checked yet. This question was written from the published exam objectives and cites the clause it comes from, but nobody has yet read it against that clause and signed for it.
It is kept out of search results and out of mock exams until they have. Read the source below before you take the answer as settled.
The options
Choose 3.
Correct Start it with nohup and put it in the background: `nohup cmd &`
Correct. nohup makes the process ignore SIGHUP, so the hangup delivered when the terminal disappears does not end it.
Correct Run it inside a screen or tmux session and detach
Correct. The terminal multiplexer owns the pseudo-terminal and survives your disconnect, so you can reattach later with `screen -r` or `tmux attach`.
Not correct Suspend it with Ctrl+Z and leave it stopped
Wrong. A stopped job makes no progress at all, and it is still owned by the session, so it does not survive the disconnect either.
Correct Background the job and then run `disown` on it
Correct. disown removes the job from the shell's job table, so bash does not send it SIGHUP when it exits.
Not correct Start it with `nice -n 19 cmd`
Wrong. nice only changes scheduling priority. It has no effect on signal handling or on the process's link to the terminal.
Why
Surviving a hangup is about SIGHUP and terminal ownership, not about priority. nohup pre-emptively ignores SIGHUP, disown stops bash from sending it, and screen or tmux keeps a terminal alive independently of your connection — the last of which also lets you get your session back.
Where this comes from
- Cited
- LPI exam objective 103.5
- What it says
- Detach processes from the controlling terminal so they persist.
Practise this
Reading one question is not practice. The trainer will draw a set from objective 103 and space the ones you get wrong.