Nohup take no effect when to close the terminal end the process running in background?
nohup command
means "run command
and ignore HUP signals".
So before we can effectively use nohup
we need to ask: when and how is SIGHUP
sent? As the Bash manual says, "Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped.". It goes on to say that the proper way to suppress this behavior is with disown
. I realize you are asking about nohup
, but it's worth calling out that disown
is the intended and easier way to accomplish what you want. Note that disown
is not equivalent to nohup
.
The reason nohup
is tricky to work with here is because it applies to a single process, whereas &
creates a background job of a whole command pipeline, which can consist of multiple processes. This means you need to nohup
each command in the pipeline in order to ensure that the individual commands don't receive a SIGHUP, e.g.:
$ nohup ls Music/*mp3 2>/dev/null | nohup xargs -d "\n" nohup mplayer &> /dev/null &
This should work, though I haven't tested it with these specific commands. If it doesn't, it's likely another process that you aren't starting directly is still receiving a SIGHUP. This is harder to address, which is exactly why we have disown
.
manishg's suggestion is also reasonable; by moving the pipeline into a separate process you can nohup
that process, which should in turn prevent a SIGHUP from reaching its children when your shell closes.
All that said, you don't need ls
and xargs
here in the first place; find
can be used to similar effect and will simplify reasoning about the command. Try:
$ nohup find Music -maxdepth 1 -name '*mp3' -exec mplayer {} + &> /dev/null &
I want to play all mp3 music in directory Music.
Usually, you don't need ls
or xargs
for that.
You can simplify your whole pipeline to mplayer Music/*mp3
✱.
This is not only safer for special filenames, but also solves your problem with nohup
:
nohup mplayer Music/*mp3 &> /dev/null &
✱ There is only one case where this command fails and `ls * | xargs` succeeds. If you have a very large number of mp3 files you might run into the command line length limit. The limit in bytes is given by `getconf ARG_MAX`. On my system it is 2097152, meaning you would need at least 8000 files assuming a maximum file name length of 255 bytes. With shorter file names, you can have even more files. For instance, if your mp3 files are usually around 40 bytes long, you can use more than 44000 files.