Re: emelFM2 lock-up when using the unpack plugin

  • From: <tpgww@xxxxxxxxxxx>
  • To: emelfm2@xxxxxxxxxxxxx
  • Date: Mon, 3 Sep 2007 23:47:35 +1000

On Mon, 3 Sep 2007 04:26:53 -0500
"Liviu Andronic" <landronimirc@xxxxxxxxx> wrote:

> On 9/3/07, Grégory SCHMITT <gy.schmitt@xxxxxxxxx> wrote:
> > Regarding subversion and proxy, I'm afraid I won't be of any help,
> > but for the time being, if you can't use subversion, you can get a
> > tarball of SVN rel. 634 there:
> > (click on "Télécharger ce
> > fichier").
> Thank you.
Yes, thanks Grégory. ATM I have about 40 files with mostly-minor changes yet to 
be committed, so providing a single file from here risks build-failure.

> > Regarding the xkill command killing only the window and not the
> > process, I experienced the same behaviour in the past. IMO, it is
> > normal.
> I do not agree with this behaviour. Applications like Mousepad, Lyx,
> Qalculate, Grip and emel sometimes, all kill their respective process
> after they lose connection to the X server. I think emel should always
> behave like this.
> >The emelfm2 process seems to be dead and not responding to
> > SIGTERM, only to SIGKILL. Maybe xkill has an option...
If the emelfm2 process is still running normally, i.e. not stuck on some mutex 
lock or otherwise hung, then a SIGTERM signal will terminate the process, after 
saving config data, cleaning up memory allocations etc. AFAIK it's not directly 
related to X-server connection. 

Or if the process is hung, then it needs a SIGKILL, because a SIGTERM can't be 
handled by the hung process.

I'm not sure exactly what xkill does, but it seems to stop the emelfm2 process 
without cleanup.


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: