Re: [gentoo-user] X hang / occasionally after using LVM

2011-09-30 Thread J.Marcos Sitorus
do you have any crashes when virtualbox was not started and no virtualbox
modules are loaded?
I was suffer another crash when I backup my data to the other partition on
LVM, when virtualbox not running
I set virtualbox modules to autoload on boot

btw the logs after a crash not after a clean boot are the usefull ones ;)
that's the problem. I was suffering this problem about a week ago. So I
don't have that log :(

 are you able to reproduce the problem with a vanilla kernel? Make sure you
are
using 2.6.38 - not .1 or greater. Reiser4 sometimes breaks with stable
releases - and 2.6.38.X was very broken...
I never use vanilla kernel. I always though that kernel with rX always
better that the kernel without rX

On Thu, Sep 29, 2011 at 11:11 PM, Volker Armin Hemmann 
volkerar...@googlemail.com wrote:

 Am Donnerstag 29 September 2011, 09:11:09 schrieb J.Marcos Sitorus:
  Hi Volker,
  Thanks for the reply.
  I have attach dmesg, xorg log, xsession-error, and kdm log.
 
  So - get back to your last working versions - oh and those lvm volumes
 are
 
  on
  new disks?
  Nope. Previously I have two separate partition. Then I delete both
 partition
  and create LVM from the free space.

 ok - did you check that the devices are error-free (with badblocks)?

 
  You did not knock the ram loose while putting them in?
 
  What do you mean by knock the ram loose?
  Sorry, English is not my mother language.

 M. Mol answered that. Since you did not put in new disks, you have hardly
 done
 any damage ;)


 btw the logs after a crash not after a clean boot are the usefull ones ;)

 A couple of questions:

 do you have any crashes when virtualbox was not started and no virtualbox
 modules are loaded?

 do you have any other odd behaviour - occasional segfaults etc?

 which options did you use when you run mkfs.reiser4?

 are you able to reproduce the problem with a vanilla kernel? Make sure you
 are
 using 2.6.38 - not .1 or greater. Reiser4 sometimes breaks with stable
 releases - and 2.6.38.X was very broken...

 --
 #163933




-- 
Salam,

J.Marcos S.
Sent from X1™


Re: Re: [gentoo-user] OT - krdc full screen view does not allow remote windows' task bar interaction

2011-09-30 Thread frares

Em 29/09/2011 18:58, Alex Schuster wo...@wonkology.org escreveu:

fra...@gmail.com writes:




 When I move the mouse down to the task bar area, the mouse pointer
 changes from the remote machine native shape to the local desktop shape,
 showing visually the fact that I can not click on any task bar icons.



Does the same happen when using rdesktop?



Wonko




Nope, rdesktop works as expected, full screen, full mouse pointer access  
across the screen.


Thanks


[gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Mark Knecht
Hi,
   Is there a portage option that will limit the number of cores used
by emerge? For instance, in a chroot on a 12 core machine I want to
limit emerge to not using more than 3 cores?

   If possible, I'd also like to limit the total disk bandwidth
consumption during emerge. For instance, when untarring a big file to
do the emerge at times the disk consumption gets to high and the
machine becomes laggy. Is there an option that addresses this?

   These questions are mostly about being able to update a chroot
mid-day without other tasks slowing down too much. I don't care how
long the chroot really takes to get a huge emerge done, but rathe just
keeping the machine very responsive while it's happening. I already
use:

MAKEOPTS=-j3
PORTAGE_NICENESS=15

which helps (I think) but it doesn't totally address either of the issues above.

Thanks,
Mark



[gentoo-user] Re: Limit number of cores used by emerge?

2011-09-30 Thread che
Mark Knecht markkne...@gmail.com writes:

 Hi,
Is there a portage option that will limit the number of cores used
 by emerge? For instance, in a chroot on a 12 core machine I want to
 limit emerge to not using more than 3 cores?

I don't think there is a portage option for that. Perhaps you could use
schedtool?

with 'schedtool -a' you can specify a list of cpus a proces may run on.


If possible, I'd also like to limit the total disk bandwidth
 consumption during emerge. For instance, when untarring a big file to
 do the emerge at times the disk consumption gets to high and the
 machine becomes laggy. Is there an option that addresses this?

perhaps ionice is the tool for that?


--
 Christer




Re: [gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Dale

Mark Knecht wrote:

Hi,
Is there a portage option that will limit the number of cores used
by emerge? For instance, in a chroot on a 12 core machine I want to
limit emerge to not using more than 3 cores?

If possible, I'd also like to limit the total disk bandwidth
consumption during emerge. For instance, when untarring a big file to
do the emerge at times the disk consumption gets to high and the
machine becomes laggy. Is there an option that addresses this?

These questions are mostly about being able to update a chroot
mid-day without other tasks slowing down too much. I don't care how
long the chroot really takes to get a huge emerge done, but rathe just
keeping the machine very responsive while it's happening. I already
use:

MAKEOPTS=-j3
PORTAGE_NICENESS=15

which helps (I think) but it doesn't totally address either of the issues above.

Thanks,
Mark




This may help:

PORTAGE_IONICE_COMMAND=ionice -c -3 -p \${PID}

Make sure you have util-linux installed since it has the ionice 
command.  I think you have to have it enabled in the kernel as well.  
I'm not certain tho.


On my machine, even if I tell emerge to only do one job at a time, it 
still staggers around the cores.  I guess it makes the CPU heat spread 
out evenly or something.


Hope that helps.

Dale

:-)  :-)



Re: [gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Michael Mol
On Fri, Sep 30, 2011 at 12:55 PM, Dale rdalek1...@gmail.com wrote:
 Mark Knecht wrote:
    Is there a portage option that will limit the number of cores used
 by emerge? For instance, in a chroot on a 12 core machine I want to
 limit emerge to not using more than 3 cores?
 On my machine, even if I tell emerge to only do one job at a time, it still
 staggers around the cores.  I guess it makes the CPU heat spread out evenly
 or something.

Difference between number of cores and which cores...-j1 should
mean it won't use more than one core at a time, but it might switch
around which core when the process gets descheduled and brought back.
(Or when a process ends and another is spawned)

-- 
:wq



Re: [gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Dale

Michael Mol wrote:

On Fri, Sep 30, 2011 at 12:55 PM, Dalerdalek1...@gmail.com  wrote:

Mark Knecht wrote:

Is there a portage option that will limit the number of cores used
by emerge? For instance, in a chroot on a 12 core machine I want to
limit emerge to not using more than 3 cores?

On my machine, even if I tell emerge to only do one job at a time, it still
staggers around the cores.  I guess it makes the CPU heat spread out evenly
or something.

Difference between number of cores and which cores...-j1 should
mean it won't use more than one core at a time, but it might switch
around which core when the process gets descheduled and brought back.
(Or when a process ends and another is spawned)




I'm not certain of why but when I am doing anything CPU intensive, it 
bounces from one core to another every 15 or 20 seconds.  I just assume 
it is a heat thing.  I created a 6Gb tarball the other day that took 
quite a while.  It looks like a bar graph equalizer with the processes 
bouncing around from core to core.  I just thought it worth mentioning 
in case the OP didn't realize this.  Heck, I have had this happen with 
Seamonkey and I don't think it even sees multiple cores or anything.


I also forgot to mention that the IONICE line goes in make.conf if you 
want it to be used each time.


Dale

:-)  :-)



Re: [gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Paul Hartman
On Fri, Sep 30, 2011 at 11:25 AM, Mark Knecht markkne...@gmail.com wrote:
 Hi,
   Is there a portage option that will limit the number of cores used
 by emerge? For instance, in a chroot on a 12 core machine I want to
 limit emerge to not using more than 3 cores?

   If possible, I'd also like to limit the total disk bandwidth
 consumption during emerge. For instance, when untarring a big file to
 do the emerge at times the disk consumption gets to high and the
 machine becomes laggy. Is there an option that addresses this?

   These questions are mostly about being able to update a chroot
 mid-day without other tasks slowing down too much. I don't care how
 long the chroot really takes to get a huge emerge done, but rathe just
 keeping the machine very responsive while it's happening. I already
 use:

 MAKEOPTS=-j3
 PORTAGE_NICENESS=15

 which helps (I think) but it doesn't totally address either of the issues 
 above.

If your MAKEOPTS is -j3 then it's not going to use more than 3 cores
at a time but it will touch all 12 cores throughout the process
because of the normal load balancing. If you want it to use only 3
specific cores, you would need to set the processor affinity (usually
done using the taskset command from sys-apps/util-linux).

For the disk I/O you can set an ionice in your make.conf like:
PORTAGE_IONICE_COMMAND=ionice -c 3 -p \${PID}

Salt to taste. :)



Re: [gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Mark Knecht
On Fri, Sep 30, 2011 at 10:28 AM, Paul Hartman
paul.hartman+gen...@gmail.com wrote:
 On Fri, Sep 30, 2011 at 11:25 AM, Mark Knecht markkne...@gmail.com wrote:
 Hi,
   Is there a portage option that will limit the number of cores used
 by emerge? For instance, in a chroot on a 12 core machine I want to
 limit emerge to not using more than 3 cores?

   If possible, I'd also like to limit the total disk bandwidth
 consumption during emerge. For instance, when untarring a big file to
 do the emerge at times the disk consumption gets to high and the
 machine becomes laggy. Is there an option that addresses this?

   These questions are mostly about being able to update a chroot
 mid-day without other tasks slowing down too much. I don't care how
 long the chroot really takes to get a huge emerge done, but rathe just
 keeping the machine very responsive while it's happening. I already
 use:

 MAKEOPTS=-j3
 PORTAGE_NICENESS=15

 which helps (I think) but it doesn't totally address either of the issues 
 above.

 If your MAKEOPTS is -j3 then it's not going to use more than 3 cores
 at a time but it will touch all 12 cores throughout the process
 because of the normal load balancing. If you want it to use only 3
 specific cores, you would need to set the processor affinity (usually
 done using the taskset command from sys-apps/util-linux).

 For the disk I/O you can set an ionice in your make.conf like:
 PORTAGE_IONICE_COMMAND=ionice -c 3 -p \${PID}

 Salt to taste. :)


Thanks to all who have answered so far. I'll give the ionice command a
try immediately. I'll try to address my view of other comments in a
single post to keep the traffic down.

My experience with -j3 is not that it limits emerge to 3 CPU cores but
rather it limits emerge to running 3 _jobs_. There's a big difference.
1 job can use 12 cores if gcc spawns a lot of stuff in parallel, which
in my experience it does. It's this parallel spawn running up to 12
cores in use which causes the machine to lag. Even when not setting
the -j option at all which results in a single package being emerged
at one time, I often use 6-12 cores in use for short periods of time
as gcc builds that package. This is completely appropriate for the
host machine. When I do updates I want them to get done ASAP. On the
other hand, for a chroot it's too much power.

Concerning which core is used, I don't care.

Concerning the 'bouncing around' aspect of multi-core processors,
that's primarily a CPU function of where it has cached data  code as
well as thermal management on chip. Internal hardware is generally
controlling what CPU gets used for what as far as I know. However even
a single emerge job (1 package being emerged) could move around from
core to core depending on what work is getting done. It's
understandable that a driver might be fundamentally associated with a
specific core's immediate L1 or L2 cache, whereas the emerge job
itself could be using other cores.

Of course, everything above is just my limited understanding of what
the hardware is doing and could be completely wrong.

Thanks,
Mark



Re: [gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Dale

Paul Hartman wrote:

On Fri, Sep 30, 2011 at 11:25 AM, Mark Knechtmarkkne...@gmail.com  wrote:

Hi,
   Is there a portage option that will limit the number of cores used
by emerge? For instance, in a chroot on a 12 core machine I want to
limit emerge to not using more than 3 cores?

   If possible, I'd also like to limit the total disk bandwidth
consumption during emerge. For instance, when untarring a big file to
do the emerge at times the disk consumption gets to high and the
machine becomes laggy. Is there an option that addresses this?

   These questions are mostly about being able to update a chroot
mid-day without other tasks slowing down too much. I don't care how
long the chroot really takes to get a huge emerge done, but rathe just
keeping the machine very responsive while it's happening. I already
use:

MAKEOPTS=-j3
PORTAGE_NICENESS=15

which helps (I think) but it doesn't totally address either of the issues above.

If your MAKEOPTS is -j3 then it's not going to use more than 3 cores
at a time but it will touch all 12 cores throughout the process
because of the normal load balancing. If you want it to use only 3
specific cores, you would need to set the processor affinity (usually
done using the taskset command from sys-apps/util-linux).

For the disk I/O you can set an ionice in your make.conf like:
PORTAGE_IONICE_COMMAND=ionice -c 3 -p \${PID}

Salt to taste. :)




Well, this is interesting:

root@fireball # emerge -1av kate
ionice: bad prio class -3
 * PORTAGE_IONICE_COMMAND returned 1
 * See the make.conf(5) man page for PORTAGE_IONICE_COMMAND usage 
instructions.


When I went to copy this, I noticed it was commented out.  Now I see 
why.  What's up with this?


I bet Mark is going to get this too.

Dale

:-)  :-)



Re: [gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Paul Hartman
On Fri, Sep 30, 2011 at 1:41 PM, Dale rdalek1...@gmail.com wrote:
 Well, this is interesting:

 root@fireball # emerge -1av kate
 ionice: bad prio class -3
  * PORTAGE_IONICE_COMMAND returned 1
  * See the make.conf(5) man page for PORTAGE_IONICE_COMMAND usage
 instructions.

 When I went to copy this, I noticed it was commented out.  Now I see why.
  What's up with this?

 I bet Mark is going to get this too.

I bet you have a typo on your ionice command in make.conf. :)

You should have -c 3 not -c -3 as I will guess you might have from
that error message about priority class -3.



Re: [gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Dale

Paul Hartman wrote:

On Fri, Sep 30, 2011 at 1:41 PM, Dalerdalek1...@gmail.com  wrote:

Well, this is interesting:

root@fireball # emerge -1av kate
ionice: bad prio class -3
  * PORTAGE_IONICE_COMMAND returned 1
  * See the make.conf(5) man page for PORTAGE_IONICE_COMMAND usage
instructions.

When I went to copy this, I noticed it was commented out.  Now I see why.
  What's up with this?

I bet Mark is going to get this too.

I bet you have a typo on your ionice command in make.conf. :)

You should have -c 3 not -c -3 as I will guess you might have from
that error message about priority class -3.




BINGO !!  That was it.  Mark, if you copy mine, remove the - in front of 
the 3.  Aw heck,


PORTAGE_IONICE_COMMAND=ionice -c 3 -p \${PID}

That one works mucho better.  ;-)

Thanks Paul for seeing my boo boo.  Thing is, I copied and pasted that 
from somewhere.


Dale

:-)  :-)



Re: [gentoo-user] Re: kde4: no hardware info without sys-apps/hal

2011-09-30 Thread Andrey Moshbear
2011/9/27 Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com:
 Check that the consolekit service is also on at bootup.

 Besides that, the udisks, upower, consolekit, policykit and udev flags
 apply here. Check they are on, particularly for kde-base/kdelibs
 (emerge -pv kdelibs).

All are enabled.

 What kdelibs (and kde, in general) version(s) are you using?

4.7.1

 Hal hasn't been needed for disk mounting nor anything else for a long time.


Consolekit has indeed been in init, but hotplug and acpi are still
non-functional.
I don't know if this is related, but the kde policykit thingy dies
shortly after login due to a buffer overflow in memcpy.

Here's the output of solid-hardware list:
Object::connect: No such signal
QDBusAbstractInterface::DeviceAdded(QString) in
/var/tmp/portage/kde-base/kdelibs-4.7.1/work/kdelibs-4.7.1/solid/solid/backends/upower/upowermanager.cpp:67
Object::connect: No such signal
QDBusAbstractInterface::DeviceRemoved(QString) in
/var/tmp/portage/kde-base/kdelibs-4.7.1/work/kdelibs-4.7.1/solid/solid/backends/upower/upowermanager.cpp:69
Object::connect: No such signal
QDBusAbstractInterface::DeviceAdded(QDBusObjectPath) in
/var/tmp/portage/kde-base/kdelibs-4.7.1/work/kdelibs-4.7.1/solid/solid/backends/udisks/udisksmanager.cpp:70
Object::connect: No such signal
QDBusAbstractInterface::DeviceRemoved(QDBusObjectPath) in
/var/tmp/portage/kde-base/kdelibs-4.7.1/work/kdelibs-4.7.1/solid/solid/backends/udisks/udisksmanager.cpp:72
Object::connect: No such signal
QDBusAbstractInterface::DeviceChanged(QDBusObjectPath) in
/var/tmp/portage/kde-base/kdelibs-4.7.1/work/kdelibs-4.7.1/solid/solid/backends/udisks/udisksmanager.cpp:74
QStringList Solid::Backends::UDisks::UDisksManager::allDevicesInternal()
 error:  org.freedesktop.DBus.Error.Spawn.ExecFailed
virtual QStringList
Solid::Backends::UPower::UPowerManager::allDevices()  error:
org.freedesktop.DBus.Error.Spawn.ExecFailed
udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXCPU:00'
udi = '/org/kde/solid/udev/sys/devices/LNXSYSTM:00/LNXCPU:01'
udi = '/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/adsp'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/audio'
udi = '/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/dsp'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/hwC0D0'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/hwC0D1'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/hwC0D2'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/mixer'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/pcmC0D0c'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/pcmC0D0p'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/pcmC0D1p'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/pcmC0D3p'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1b.0/sound/card0/controlC0'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1c.1/:03:00.0/net/wlan0'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1c.5/:08:00.0/net/eth0'
udi = 
'/org/kde/solid/udev/sys/devices/pci:00/:00:1d.7/usb2/2-5/2-5:1.0/video4linux/video0'
udi = '/org/kde/solid/udev/sys/devices/platform/serial8250/tty/ttyS0'
udi = '/org/kde/solid/udev/sys/devices/platform/serial8250/tty/ttyS1'
udi = '/org/kde/solid/udev/sys/devices/platform/serial8250/tty/ttyS2'
udi = '/org/kde/solid/udev/sys/devices/platform/serial8250/tty/ttyS3'
udi = '/org/kde/solid/udev/sys/devices/virtual/net/lo'
udi = '/org/kde/solid/udev/sys/devices/virtual/net/sit0'
udi = '/org/kde/solid/udev/sys/devices/virtual/sound/seq'
udi = '/org/kde/solid/udev/sys/devices/virtual/sound/sequencer'
udi = '/org/kde/solid/udev/sys/devices/virtual/sound/sequencer2'
udi = '/org/kde/solid/udev/sys/devices/virtual/sound/timer'
udi = '/org/freedesktop/UDisks'
udi = '/org/kde/fstab'
udi = '/org/kde/upnp'

Also, recurring errors in the form of Failed to execute program
/usr/libexec/dbus-daemon-launch-helper: Success, which is determined
to be EPERM, which is probably due to Bad Things in policykit.



Re: [gentoo-user] Re: kde4: no hardware info without sys-apps/hal

2011-09-30 Thread Dale

Andrey Moshbear wrote:

2011/9/27 Jesús J. Guerrero Botellajesus.guerrero.bote...@gmail.com:

Check that the consolekit service is also on at bootup.

Besides that, the udisks, upower, consolekit, policykit and udev flags
apply here. Check they are on, particularly for kde-base/kdelibs
(emerge -pv kdelibs).

All are enabled.


What kdelibs (and kde, in general) version(s) are you using?

4.7.1


Hal hasn't been needed for disk mounting nor anything else for a long time.


Consolekit has indeed been in init, but hotplug and acpi are still
non-functional.
I don't know if this is related, but the kde policykit thingy dies
shortly after login due to a buffer overflow in memcpy.





Here is a list of what I have installed and as far as I know, everything 
works.  This includes my printer, camera and USB drives when inserted.


root@fireball / # equery l dbus kdelibs polkit consolekit
 * Searching for dbus ...
[IP-] [  ] sys-apps/dbus-1.4.12:0

 * Searching for kdelibs ...
[IP-] [  ] kde-base/kdelibs-4.7.1-r2:4

 * Searching for polkit ...
[IP-] [  ] sys-auth/polkit-0.101-r1:0

 * Searching for consolekit ...
[IP-] [  ] sys-auth/consolekit-0.4.5-r1:0
root@fireball / #

Maybe compare those.  If you need me to, I can post the emerge info with 
USE flags too.


Dale

:-)  :-)



Re: [gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Neil Bothwick
On Fri, 30 Sep 2011 11:15:16 -0700, Mark Knecht wrote:

  If your MAKEOPTS is -j3 then it's not going to use more than 3 cores
  at a time but it will touch all 12 cores throughout the process
  because of the normal load balancing. If you want it to use only 3
  specific cores, you would need to set the processor affinity (usually
  done using the taskset command from sys-apps/util-linux).

 My experience with -j3 is not that it limits emerge to 3 CPU cores but
 rather it limits emerge to running 3 _jobs_. There's a big difference.
 1 job can use 12 cores if gcc spawns a lot of stuff in parallel, which
 in my experience it does. It's this parallel spawn running up to 12
 cores in use which causes the machine to lag. Even when not setting
 the -j option at all which results in a single package being emerged
 at one time, I often use 6-12 cores in use for short periods of time
 as gcc builds that package.

That's the --jobs option for emerge. The suggestion was to set the -J
option in MAKEOPTS, which tells GCC how many compilation threads to run
at once, and that's one core per thread. You'll also need to set -j 1 for
emerge, which will also reduce the amount of disk thrashing that can
happen when two package hit unpack at the same time.


-- 
Neil Bothwick

If at first you don't succeed, skydiving is not for you.


signature.asc
Description: PGP signature


Re: [gentoo-user] Re: kde4: no hardware info without sys-apps/hal

2011-09-30 Thread Neil Bothwick
On Fri, 30 Sep 2011 16:34:36 -0400, Andrey Moshbear wrote:

 Also, recurring errors in the form of Failed to execute program
 /usr/libexec/dbus-daemon-launch-helper: Success, which is determined
 to be EPERM, which is probably due to Bad Things in policykit.

This one caused m,y hotplugging to stop working in KDE. The fix was

chmod o+x /usr/libexec/dbus-daemon-launch-helper


-- 
Neil Bothwick

... Yummy, said Pooh, as he hilted his paw into the honeypot.


signature.asc
Description: PGP signature


Re: [gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Mark Knecht
On Fri, Sep 30, 2011 at 3:09 PM, Neil Bothwick n...@digimed.co.uk wrote:
 On Fri, 30 Sep 2011 11:15:16 -0700, Mark Knecht wrote:

  If your MAKEOPTS is -j3 then it's not going to use more than 3 cores
  at a time but it will touch all 12 cores throughout the process
  because of the normal load balancing. If you want it to use only 3
  specific cores, you would need to set the processor affinity (usually
  done using the taskset command from sys-apps/util-linux).

 My experience with -j3 is not that it limits emerge to 3 CPU cores but
 rather it limits emerge to running 3 _jobs_. There's a big difference.
 1 job can use 12 cores if gcc spawns a lot of stuff in parallel, which
 in my experience it does. It's this parallel spawn running up to 12
 cores in use which causes the machine to lag. Even when not setting
 the -j option at all which results in a single package being emerged
 at one time, I often use 6-12 cores in use for short periods of time
 as gcc builds that package.

 That's the --jobs option for emerge. The suggestion was to set the -J
 option in MAKEOPTS, which tells GCC how many compilation threads to run
 at once, and that's one core per thread. You'll also need to set -j 1 for
 emerge, which will also reduce the amount of disk thrashing that can
 happen when two package hit unpack at the same time.


 --
 Neil Bothwick

OK, my bad for confusing the two. Currently make.conf in the chroot says:

MAKEOPTS=-j3

and when I run emerge in the chroot it's typically

emerge -DuN -j2 @world

so I think that's about right, or would hope it is anyway. If you see
a problem please let me know.

I'll add the ionice stuff this weekend and see how it goes.

Thanks,
Mark



Re: [gentoo-user] Limit number of cores used by emerge?

2011-09-30 Thread Paul Hartman
On Fri, Sep 30, 2011 at 5:47 PM, Mark Knecht markkne...@gmail.com wrote:
 OK, my bad for confusing the two. Currently make.conf in the chroot says:

 MAKEOPTS=-j3

 and when I run emerge in the chroot it's typically

 emerge -DuN -j2 @world

 so I think that's about right, or would hope it is anyway. If you see
 a problem please let me know.

The -j2 on emerge means it'll run 2 makes at once, and each make is
getting -j3, so it'll use (up to) 6 cores at once. You probably want
to just stop using -j option for emerge entirely and stick to the
MAKEOPTS one.



Re: [gentoo-user] {OT} Development framework with access restriction?

2011-09-30 Thread Grant
 svn can restrict access to directories

 http://stackoverflow.com/questions/2288810/how-to-restrict-svn-repository-user-account-to-one-directory

That would be perfect if it allowed access per file instead of per
directory.  I thought about re-arranging the layout to accommodate
that limitation but I don't think it makes sense.

After more research, I think subversion's path-based authorization
*does* in fact work with files and not just folders.  This might be
the solution I've been looking for.  I will report back on this after
more research.

 do you not want him to change it or do you not want him to be able to
 read your code?

I do not want him to be able to read or write any files except for the
specific file or files I want him to work on.  This becomes
complicated because he needs to be able to test his changes in a
working version of the system as he goes.  The files to be worked on
contain server-side website code all of which I don't want to give
away to the dev.

- Grant



Re: [gentoo-user] {OT} Development framework with access restriction?

2011-09-30 Thread Grant
 I'm not sure if you are overcomplicating this by trying to use Unix
 permission.  Have you instead considered webdav?  You can restrict this to
 particular (apache) users/groups, directories, files.  It also uses lockfiles
 so with two users editing a file simultaneously will cause a warning when you
 try to save it.

How does webdav relate to something like subversion?  Do they
compliment each other or are they substitutes?

- Grant



Re: [gentoo-user] {OT} Development framework with access restriction?

2011-09-30 Thread Grant
 For some reason I thought SFTP would provide access control but now
 I'm thinking it's just like SSH in that access control is based on
 file ownership and permissions?  If that's the case, can anyone think
 of a better way to control remote access to my files than chmod/chown?

 ACLs.


 We went this route once too. We had a developer ($USER) who was supposed
 to have access to just one subdirectory of /var/www.

 I took notes, assuming /etc, /root, and /usr have correct permissions:

   1. A group named ssh_users was created. The $USER account was
      added as a member of this group.

   2. The ssh_users group was granted the ability to traverse /var/www:

      setfacl -m group:ssh_users:--x /var/www

      This is necessary to allow the $USER user to chdir into its
      home directory in /var/www/$HIS_HOME_DIR.

   3. A default ACL was set on /var/www which will apply to each new
      subdirectory created within it.

      setfacl -d --set u::rwx,g::rx,g:ssh_users:-,o::rx /var/www

      This prevents members of the ssh_users group from traversing any
      newly-created subdirectories of /var/www.

   4. The default ACL described above was applied manually to each of
      the existing subdirectories of /var/www:

      setfacl -m g:ssh_users:- /var/www/*

      Warning: At the time of writing, there were no regular files in
      /var/www, so the above command makes sense. Don't blindly run it
      again without checking.

   5. The $USER user was granted full read/write/traverse permissions
      on its home directory and all subdirectories/files contained
      therein:

      setfacl -R -m u:$USER:rwx /var/www/$HIS_HOME_DIR

   6. At this point, we need to change the default ACLs of every
      directory within /var/www/$HIS_HOME_DIR. This is so that, when
      $USER creates a new file/directory somewhere beneath its home
      directory, it has access to the newly-created file or directory:

      setfacl -d -R --set u::rwx,u:$USER:rwx,g::rx,o::rx /var/www
      /$HIS_HOME_DIR

      This command sets the default ACL recursively, and is smart
      enough to only apply the command to directories.

Thanks for that.  I haven't thought it all the way through, but if
Unix ownership and permissions aren't granular enough and subversion's
path-based authorization won't work, I will need to use ACLs.  I think
both subversion's path-based authorization and Unix
ownership/permissions would be simpler to implement and maintain than
ACLs so I'm hoping it doesn't come to that.

- Grant



Re: [gentoo-user] {OT} Development framework with access restriction?

2011-09-30 Thread Michael Orlitzky
On 09/30/2011 07:59 PM, Grant wrote:
 
 Thanks for that.  I haven't thought it all the way through, but if
 Unix ownership and permissions aren't granular enough and subversion's
 path-based authorization won't work, I will need to use ACLs.  I think
 both subversion's path-based authorization and Unix
 ownership/permissions would be simpler to implement and maintain than
 ACLs so I'm hoping it doesn't come to that.
 

ACLs really aren't as bad as they look at first. They work just like
permissions on Windows, which are one of the few things it does right.
My example is made much more difficult because /var/www contains
directories writable by other customers.

I know *my* config.php files are chgrp apache and chmod 660, but I don't
expect everyone else to be so careful (and they shouldn't have to be).

If you are going to go the version control route, I would suggest
setting up a new repository with only the code that he will be working
on. You can use a post-update script (or whatever svn calls them) on the
server to pull his code into production. He doesn't need to access the
files directly.



Re: [gentoo-user] {OT} Development framework with access restriction?

2011-09-30 Thread Pandu Poluan
On Oct 1, 2011 7:26 AM, Michael Orlitzky mich...@orlitzky.com wrote:

 On 09/30/2011 07:59 PM, Grant wrote:
 
  Thanks for that.  I haven't thought it all the way through, but if
  Unix ownership and permissions aren't granular enough and subversion's
  path-based authorization won't work, I will need to use ACLs.  I think
  both subversion's path-based authorization and Unix
  ownership/permissions would be simpler to implement and maintain than
  ACLs so I'm hoping it doesn't come to that.
 

 ACLs really aren't as bad as they look at first. They work just like
 permissions on Windows, which are one of the few things it does right.
 My example is made much more difficult because /var/www contains
 directories writable by other customers.

 I know *my* config.php files are chgrp apache and chmod 660, but I don't
 expect everyone else to be so careful (and they shouldn't have to be).

 If you are going to go the version control route, I would suggest
 setting up a new repository with only the code that he will be working
 on. You can use a post-update script (or whatever svn calls them) on the
 server to pull his code into production. He doesn't need to access the
 files directly.


+1 on production server pulling from $VCS.

I'm currently assisting a friend of mine, who's the CEO of a business
incubator. In order to force them startups to use the $VCS, we require them
to first commit their codes to the $VCS, then have a script pull the newest
version into production.

At first, they whined. Oh, how they whined! But after the $VCS saved their
bacons many times, now they're firm believers in version control :-)

Rgds,