Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I can run this command:

$ play mylist.m3u

And music plays.

I can then press Ctrl-Z to suspend the job, and issue bg to have it run in the background.

However, if I then run disown and exit, the music stops playing, even though the play command still shows up in ps.

I would expect the music to keep playing.

Also interesting

I run the command

$ play mylist.m3u &

Music does not play. The job shows as the stopped status.

I can also run the command

$ nohup play mylist.m3u &

And no music plays - the job immediately stops.


$ nohup play mylist.m3u

Does have music play, but I can't disown it, as before.

It seems like all these are related.

Most programs behave well when disowned or run through nohup, but not SoX.

Does anyone know why?

share|improve this question
If you want to play music as server, use mpd and ncmpc/mpc... – Jiri Xichtkniha May 31 '12 at 9:02
@JiriXichtkniha: Thanks - I already run xmms2, so it's no problem. I am more just curious why this fails. I want to know what is special about SoX that causes this odd behavior. – jwd May 31 '12 at 14:17
up vote 1 down vote accepted

SoX wants/needs input & output... by typing 'play xxxx' in the console, you're running it normally, with stdin & stdout (& stderr) all connected.

When you background the job (with &), it starts, then is paused since it's waiting for access to stdin & stdout.

Same thing occurs when you 'nohup' a job. If it needs keyboard input, it'll "block", and get paused by the system until it receives access to stdin.

disown'ing a process effectively cuts it off from stdin & stdout which were connected to the console which started the process.

It's still "running", but is blocked (paused) by the system since it's waiting for access to stdin & stdout.

share|improve this answer
Do you know why it successfully runs in 'bg' mode, while the controlling terminal still exists? Is stdin still active in that mode, just nothing sent to it? – jwd Jul 6 '12 at 14:50
That'd be my best guess. Depends on the program and how it handles its input & output too. – lornix Jul 6 '12 at 14:58

For the rare person who, like me, both had this problem and finally managed to google for something that wasn't about baseball* and want an actual solution:

$ play whatever.wav &>/dev/null </dev/null &

That runs in the background without stopping.

* The Red Sox of Boston play baseball, and apparently some players prefer the limelight to the background. Grumble.

share|improve this answer
Cool! I am curious - why are there two &? I'm unfamiliar with that syntax. – jwd Oct 10 '12 at 16:38
"&>/dev/null" means "Redirect both stdout and stderr to /dev/null." It's analogous to ">/dev/null 2>&1". The second ampersand just puts the job in the background in the usual way. – Tom Olson Oct 18 '12 at 14:00

It's also possible to use the -q option to make sure SoX doesn't write to std-whatever, without redirecting to /dev/null.

$ play filename -q &
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.