Hide Forgot
Description of problem: When libesd spawns off an esd daemon, it does not close (or reopen) several file descriptors. In particular, I have an application that uses SDL for sound. I run the application, reading from its stdout until it closes. My application kicks off an esd daemon that inherits the same stdout. My app exits, but I do not receive an EOF because the esd daemon still has the FIFO open. The esd I am using ends up with stdin, stdout, stderr, and sometimes file descriptor 9 tied to the terminal I run the app from (if I run it from a terminal). Version-Release number of selected component (if applicable): esound-0.2.28-4 and esound-0.2.28-5.1 How reproducible: Always Steps to Reproduce: 1. Write an app that uses SDL for sound. 2. Kill any existing esd daemons 3. Run the app 4. Find the esd daemon's pid 5. Run lsof -p (pid) Actual results: You'll see at least fds 0, 1, and 2 set to the same thing as your app (probably its terminal). You may see fd 9 or something like that tied to the same place; I'm not sure. (Perhaps my app is dup'ing the file descriptor to cause that?) Expected results: No file descriptors should be inherited from the parent process other than the intentionally-inherited FIFOs. They can be opened to /dev/null or a log file or whatever. Workaround: setenv("ESD_SPAWN_OPTIONS", "-h 2>/dev/null; perl -MPOSIX -le 'opendir(D, q(/proc/self/fd)); @fd=readdir(D); @fd=sort grep { readlink(qq(/proc/self/fd/$_)) !~ /^((socket|pipe):|dsp)/ } @fd; POSIX::close($fd[-1]) if $fd[-1] > 2; exec(q(/usr/bin/esd), @ARGV)' -- -terminate -nobeeps -as 2 >/dev/null 2>&1 </dev/null", 1); Heh.
Workaround is buggy. The spawning shell would still have the same file descriptors open. Here's a better, but still ridiculous, one: setenv("ESD_SPAWN_OPTIONS", "-h 2>/dev/null; exec >/dev/null 2>&1 </dev/null; perl -MPOSIX -le 'opendir(D, q(/proc/self/fd)); @fd=readdir(D); @fd=sort grep { readlink(qq(/proc/self/fd/$_)) !~ /^((socket|pipe):|dsp)/ } @fd; POSIX::close($fd[-1]) if $fd[-1] > 2; exec(q(/usr/bin/esd), @ARGV)' -- -terminate -nobeeps -as 2", 1)
This is already fixed in more recent versions of esound, as per the upstream bug: http://bugzilla.gnome.org/show_bug.cgi?id=333186 Let me know whether this is a problem for you in later versions, as, unfortunately RHEL3 updates are now closed.