Re: Extreme slowdown on Debian stable

[Germán Arias]

Hi

El sáb, 13-06-2015 a las 11:25 +0200, Andrea D'Amore escribió:
> On 13 June 2015 at 02:24, Riccardo Mottola <riccardo.mottola@libero.it> wrote:
> > Never seen it that way. I have noticed sometimes on certain setups very long
> > initial delay or continuous delay due to auto-starting of gpbs.
> > Try to start gdnc and gbps manually before. Check with ps that they are
> > running, then start an application: see if it helps.
> 
> Seems we have a winner here.
> I went with this before trying valgrind because I remember
> ProjectCenter was printing something about gpbs.
> 
> Looking for gpbs and gdnc led me to [1] where I learned I had to setup
> the environment. I figure the fact that the daemons weren't starting
> automatically as stated in [1] is because I wasn't setting any GNUstep
> envinronment at all.
> 
> With GNUstep.sh sourced in bash profile I could start ProjectCenter
> without manually starting gpbs and the program behaved as expected.
> 
> 
> A couple extra questions:
> 
>  1. Has anyone already got an available environment setup script for fish 
> shell?
> 
> 
>  2. If either of gpbs or gdnc is running in a terminal window and the
> window gets resized then the daemon dies with "killed by signal 28".
> This happens as well in a tmux pane if it gets split.
> 
> I figure this wouldn't be much of an issue if the daemons are started
> in background but why is this happening at all?
> 
> 
>  3. on exiting ProjectCenter using File > Quit gpbs crashed with:
> 
>     Uncaught exception NSPasteboardCommunicationException, reason:
> invalidated while awaiting reply
> 
> trying to start gpbs again after that resulted in:
> 
>     $ gpbs --no-fork --verbose
>     X Error of failed request:  BadAtom (invalid Atom parameter)
>       Major opcode of failed request:  17 (X_GetAtomName)
>       Atom id in failed request:  0x0
>       Serial number of failed request:  54
>       Current serial number in output stream:  54
> 
> and I had to logout from the X session in order to start gpbs again.
> This happened with bash as login shell, with GNUstep.sh sourced in
> profile - I checked the env for GNUSTEP_* variables and those were
> there.
> I figure that the pasteboard server shouldn't crash and be spawned
> again at each application start.
> What's that error about?
> Could gpbs be restarted without logging out?
> 
> 
> [1] 
> http://www.gnustep.org/resources/documentation/User/GNUstep/gnustep-howto_4.html
> 
> 
> Regards
> 

This is a bit strange, because the debian packages uses the default
layout (fhs), so you don't need source the GNUstep.sh script. Are you
sure you don't have remains of other GNUstep installation?

Germán