# consolekit allocates 1/2 VIRT of all mem, seamonkey fails

## kernelOfTruth

Hi,

now I understand why everyone is ranting about the *kit stuff:

is there a good reason why policykit allocates HALF of memory ?

 *Quote:*   

> ps axuw | grep console
> 
> root      5391  0.0  0.0 4187060 3596 ?        Ssl  01:23   0:00 /usr/sbin/console-kit-daemon
> 
> root      8025  0.0  0.0  29708   988 pts/0    R+   01:33   0:00 grep --color=auto console
> ...

 

that's 4 GB out of 8 GB (!) - and that right from the start   :Evil or Very Mad: 

for weeks I've been trying to compile seamonkey and it continuously showed "can't allocate" errors at various stages during configuration and/or compilation ( e.g. seamonkey config/autoconf.mk: *** "Cannot allocate memory. Stop." )

only by killing and closing off everything else and going to the bare system (killing console-kit-daemon seems to have been the crucial step, get it running leads again to failure of the compilation attempt )

it successfully compiled - I even had to choose conservative CFLAGS and LDFLAGS

so it in part is an issue with seamonkey but when running a full desktop system - even firefox fails to compile also showing the "cannot allocate memory" message

How can I limit virtual memory size of consolekit ?

downgrade ? upgrade ?

modify the source ? any configuration file ?

Many thanks in advance for your help   :Smile: 

references:

https://www.centos.org/forums/viewtopic.php?t=4979

https://bugzilla.redhat.com/show_bug.cgi?id=473547

----------

## s4e8

set /proc/sys/vm/overcommit_memory to 1.

----------

## Ant P.

What does `cat /proc/$pid/maps` look like?

----------

## kernelOfTruth

 *s4e8 wrote:*   

> set /proc/sys/vm/overcommit_memory to 1.

 

already tried that - it only allowed compilation to go a little bit further then showed the same error message

 *Ant P. wrote:*   

> What does `cat /proc/$pid/maps` look like?

 

doesn't exist ?

 *Quote:*   

> cat /proc/$pid/maps
> 
> cat: /proc//maps: No such file or directory

 

 *Quote:*   

> `cat /proc/$pid/maps`
> 
> cat: /proc//maps: No such file or directory

 

kernel is 3.14-based

like I wrote above: removing everything unnecessary from memory allowed it to compile, so it's rather annoying having to go through all that while compiling firefox & seamonkey (haven't tried thunderbird yet, but should be similar behavior)

even swapoff of the swap portion in memory (zram device of 8 GB - I know a little overhead, will adjust that later) and removing any /var/tmp folder in memory (zram, 4 GB) - didn't make a change

/tmp is 4 GB tmpfs in memory; zswap is enabled (this allows the system to run much smoother and better than without - didn't pose a problem in the past, nothing obvious changed)

total Memory is 8 GB of RAM

this also happened on 3.13-based kernel

thanks so far

----------

## Ant P.

Try replacing the "$pid" in that example code with the actual PID of consolekit.

----------

## Anon-E-moose

I would boot into console mode or single user mode (after downloading source) and do the compilation, then go back to graphics mode.

 *Quote:*   

> /tmp is 4 GB tmpfs

 

Also this will bite you once /tmp starts getting used, better to not use it for the compile.

----------

## kernelOfTruth

 *Ant P. wrote:*   

> Try replacing the "$pid" in that example code with the actual PID of consolekit.

 

/facepalm

sorry   :Razz: 

 *Quote:*   

> pidof console-kit-daemon
> 
> 10026
> 
> 

 

http://pastebin.com/cWBHD1w0 <-- output probably too large to post here

 *Anon-E-moose wrote:*   

> I would boot into console mode or single user mode (after downloading source) and do the compilation, then go back to graphics mode.
> 
>  *Quote:*   /tmp is 4 GB tmpfs 
> 
> Also this will bite you once /tmp starts getting used, better to not use it for the compile.

 

that's what I did - which is quite different from compiling it in graphics, usual mode - but if it works - why not   :Smile: 

yes, it can get quite ugly when /tmp is completely full - the system becomes almost unresponsive

therefore /var/tmp (and /var/tmp/portage is set to the compilation directory) is on a separate, zram drive

----------

## kernelOfTruth

turned out it probably was a mix of

toolchain issues and kernel issues

always living on the bleeding edge I had compiled glibc-2.19 with binutils 2.24.51.0.3, switching back to 2.24 and re-compiling glibc with it 

and adding some additional patchsets onto the kernel (heavily patched 3.14) - now firefox, thunderbird and seamonkey compiled without issues twice already

Thanks for your attention and support   :Smile: 

----------

