Re: emelFM2 lock-up when using the unpack plugin

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:
> > http://dl.free.fr/cfdUPJ3oU/emelFM2.tar.gz (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.

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: