Re: emelfM2 pre-release available

On Fri, 22 Dec 2006 00:19:16 -0500
"Jonathan A. Irwin" <jnthn_gmane@xxxxxxxxx> wrote:

> Couple of problems here. Maybe two symptoms of the same problem? 
> 
> For one... I can no longer get videos to play with mplayer.
> 
> For instance, I have:
> 
> mplayer -quiet %f
> 
> as the default action for video files. WHen a video is double clicked,
> e2 reports in the output pane that the action has executed, but there
> is not the usual informational output from mplayer, and the video never
> starts playing.
> 
> A quick ps ax, shows:
> 
> 18296 ?        Z      0:00 [mplayer] <defunct>
> 
> And debug output says:
> 
> [DEBUG ] child output fd = 12, child error fd = 14, max monitorable fd = 1024
> [DEBUG ] ending after waitpid returned ERROR -1, with errno 22
> [DEBUG ] Unknown process (-1) completion report !!
This is going to get a bit technical, I'm afraid ...

A [g]libc function call:

    endpid = waitpid (-pid, &exitstatus, WNOHANG
  #ifdef WCONTINUED
        | WCONTINUED
  #endif
   | WUNTRACED);

is unexpectedly reporting an error. It (22 == EINVAL) is indicating that one or 
more of the W* parameters is invalid. That's interesting, as the same function 
was used in a similar way in prior versions (except that the arguments had -1 
instead of -pid).

First, can you check for anything informative about waitpid() for your specific 
glibc ?


> What's worse... apparently I can no longer quit e2 without killing child
> processes. For example, my image viewer... when I double click an image
> file, the image is opened in gqview. In e2 0.3.1, if I then quit e2, the
> gqview instance remains running, in the new prerelase, if I quit ew2, it
> takes gqview down with it. :(
That's a deliberate change. Not for any compelling reason, but to make commands 
consistent with actions (which must be cancelled  when a session ends) and a 
probably-mistaken concern about managing zombie processes. It could readily be 
reversed.

Leaving aside any surprise about the change, I wonder which is the "proper" way 
to handle this ?

Regards
Tom


-- 
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: