[buildd-tools-devel] Unresponsive mouse in X when compiling with schroot

Fri Jul 24 09:44:43 UTC 2009

Hello Roger,
On Wed, Jul 22, 2009 at 09:55:02PM +0100, Roger Leigh wrote:
> On Wed, Jul 22, 2009 at 06:15:29PM +0200, Helge Kreutzmann wrote:
> > On Wed, Jul 22, 2009 at 04:45:20PM +0100, Roger Leigh wrote:
> > > On Wed, Jul 22, 2009 at 03:10:07PM +0200, Helge Kreutzmann wrote:
> > > 
> > > [poor responsiveness]
> > > 
> > > > Is there any experience in your team what setting might cause this? Is
> > > > there some way to "renice" the schroot (I don't mind longer
> > > > compilation times) so that the load on the system is reduced hence
> > > > keeping the mouse under X usable?
> > > 
> > > I can't say I've noticed this myself.  It's indicative of a high system
> > > load, but it's not clear from your description what the cause is.
> > 
> > Strange thing is, if I compile the same software outside the chroot
> > (using fakeroot) the load is approximately the same (around 1) and the
> > system is still responsive.
> 
> Are you using sbuild to build in the chroot, or are you building
> using exactly the same command as outside?  (Not that this should
> make a difference--but it's a possible source of variation.)

I am using the same command (fakeroot make -f debian/rules binary),
except that there is a slight shell script wrapper which I call, which
essentically upgrades the chroot before building and jumps into the
right directories, but during that time the responsivness is till ok
(even during configure time the responsiveness is ok, it just starts
when the main build is running).

> > > Could you provide your schroot configuration for the chroot in
> > > question? (schroot --config -c <chroot>).
> > 
> > remaxp:~# schroot --config -c sid
> > # schroot-Konfiguration erzeugt von schroot 1.2.2 am 22. Juli 2009
> > 
> > [sid]
> > location=/var/chroot/sid
> > run-exec-scripts=false
> > run-setup-scripts=false
> > script-config=script-defaults
> > type=plain
> 
> That's a very standard setup.  You aren't even doing any automatic
> filesystem mounting with type=directory or running any setup
> scripts.  With this setup, schroot should be equivalent to
> "sudo /usr/sbin/chroot <command>", and shouldn't be causing any
> extra overhead.
> 
> Do you see the same extra load or lack of responsiveness if using
> /usr/sbin/chroot in place of schroot?

Yes. (Does it matter, that for convenience I don't use sudo but issue
that directly by root?).

> > I often monitor the compile using htop, which showed (to my eyes) nothing
> > strange. The load was around 1 and I could see make and gcc running.
> > It looked fairly straight forward (haven't compared to the outside
> > compile due to strong differences like paths, gcc version etc.)
> 
> I guess it depends on what causes the problem as to how this affects
> the system load.  I think it's more likely to be I/O than CPU, but
> both are a little odd, since it shouldn't be using any more than when
> run on the host system.
> 
> > I just installed iotop, but probably will need to recompile my kernel:
> > - Linux >= 2.6.20 with I/O accounting support: Not found
> 
> Yes.  I'm using iotop on 2.6.29/2.6.30.

I rebuild my kernel (2.6.27.10 with grsec) now with I/O accounting
support, and I also disabled all chroot restrictions. I will then
(after the next reboot) see if that changed things.

> BTW, it's possible that this is a kernel issue with e.g. the
> scheduler or something.  It might be worth trying a newer kernel
> if you have the possibility of doing so.

Well, old kernels (something below 2.6.20) do not exhibit this
problem, and the latest stable grsec is currently for 2.6.27, but for
testing I can surley jump to a newer kernel (but first I see, as
stated above, if the chroot options change the symptoms).

> > > Renicing is certainly possible.  In your configuration
> > >   command-prefix=nice
> > > should do the trick.  However, command-prefix was originally
> > > written to just run a single command with no arguments--it
> > > might well not support arguments (originally added to prefix
> > > the command with linux32 prior to integrated personality support).
> > 
> > According to schroot.conf(5) it does accept arguments?  Anyhow, I can't
> > get it to work:
> > /usr/bin/nice: 10: File or directory not found
> 
> Ah, it's not doing a path search for nice, so you need to use
>   command-prefix=/usr/bin/nice
> or
>   command-prefix=/usr/bin/nice,-n,15
> to use a nice value of 15.  This is all working as designed, but I
> should really get it to find the command in $PATH rather than
> requiring an absolute path (as already done for the real command to
> exec).

Yes, this works (was missing the "-n"). The result is that with 10 the
slugglishness is reduced, but still clearly visible (and still too
much to really use the mouse for more than selecting focus of a
window).

> > Since the compile is within a script, I tried adding the nice within 
> > that script, but
> > /usr/bin/nice 10 fakeroot ...  
> > neither works.
> 
> This should definitely work.  You might need "-n 10" rather than
> just "10"

Yes, sorry for not reading the man page before trying. Haven't used
nice for some time.

> > > Since schroot runs setuid root, we can call nice(2) directly
> > > before exec()ing the command.  We could add a nice=level parameter
> > > to the configuration file.  That's also a simple change which I
> > > would be happy to make.
> > 
> > If its simple, maybe you could "hack" it in and make it downloadable
> > somewhere (fine if in source, I can build it myself, using the
> > previous debian patch if possible).
> 
> I'll add this to the current development branch.  Since I think
> the command-prefix trick should work for current releases, I'll
> schedule this for a future release.  If you want it, I can
> probably make a patch for current stable releases, though.

I don't think I need it currently, thanks for the offer.

> > > Since renicing is really only working around the poor performance,
> > > it would be great to find out in more detail what the underlying
> > > cause is, so we can (if possible) address that directly.
> > 
> > Yes. I guess the first step is to build a new kernel for running
> > iotop?
> 
> I think that would be a useful first step, though I'm afraid I
> don't really have many more suggestions as to how to investigate
> further than that.  It may be that linux-kernel or debian-devel
> are better places with more expertise in this area, unless anyone
> else on buildd-tools-devel has any better ideas?

I will reboot in this new kernel later and see how things changed. If
disabling grsec on chroot helps I try to narrow down which option
causes this. Anyhow, I will return to you later (probably it'll take a
few days) with the results.

Thanks very much for your help so far.

Greetings

           Helge

-- 
      Dr. Helge Kreutzmann                     debian at helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20090724/56935654/attachment.pgp>