In my personal shell environment, I have a (soft) ulimit for virtual memory set to 512 megs (that's because I do a lot of development and don't want a runaway process killing my machine). Running emerge through sudo causes emerges of some packages, particularly Java-related ones, to fail, because of lack of virtual memory (what Java needs with 512M+ of VM space is another story, but whatever). For example with commons-logging: >>> Compiling source in /var/tmp/portage/dev-java/commons-logging-1.1-r2/work/commons-logging-1.1-src/ ... Error occurred during initialization of VM Could not reserve enough space for code cache !!! ERROR: dev-java/commons-logging-1.1-r2 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' environment, line 4835: Called src_compile ebuild.sh, line 1304: Called java-pkg-2_src_compile java-pkg-2.eclass, line 84: Called eant 'compile' '-f' 'build.xml' java-utils-2.eclass, line 1737: Called die !!! eant failed !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/dev-java/commons-logging-1.1-r2/temp/build.log'. !!! When you file a bug report, please include the following information: GENTOO_VM=blackdown-jdk-1.4.2 CLASSPATH="" JAVA_HOME="/opt/blackdown-jdk-1.4.2.03" JAVACFLAGS="-source 1.3 -target 1.3" COMPILER="javac" Whereas if I set (in my user shell) an unlimited bound on virtual memory, the emerge runs fine. Reproducible: Always Steps to Reproduce: 1. ulimit -v -S 524288 2. emerge commons-logging Actual Results: Fails with an error message as shown in summary. Expected Results: I would expect that emerge would ignore any user-set ulimits (particularly soft limits, and given that emerge runs as root, the hard limits as well, up to the system-defined maximum) and the compilation would succeed. (Actually, I would have expected sudo itself to remove those limits, but emerge should ignore them in any case). Conceivably a user would want to set resource limits on an emerge process, but that should not be the default. Perhaps a --inherit-ulimits flag or something would cause it to inherit from the spawned shell. Obvious workaround is to remove any soft limits (particularly related to max RSS/memory/vm size) prior to running emerge. (motoko ~)$ emerge --info Portage 2.1.2.2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.20.3 x86_64) ================================================================= System uname: 2.6.20.3 x86_64 Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz Gentoo Base System release 1.12.9 Timestamp of tree: Sat, 21 Apr 2007 07:00:01 +0000 ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.31-r5 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -O2 -pipe -momit-leaf-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/php/apache1-php5/ext-active/ /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=nocona -O2 -pipe -momit-leaf-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://mirrors.acm.cs.rpi.edu/gentoo/ http://gentoo.mirrors.pair.com http://gentoo.oregonstate.edu" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac alsa amd64 apache2 arts bash-completion berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dbus doc dri dvd dvdr dvdread emacs emboss encode esd fam ffmpeg firefox flac fortran gdbm gif gpm gstreamer gtk gtk2 hal iconv ipv6 isdnlog jpeg ldap libg++ mad mbox midi mikmod mp3 mpeg ncurses nls nptl nptlonly offensive ogg opengl oss pam pcre perl png ppds pppd python qt4 quicktime readline reflection sdl session spell spl ssl tcpd tetex threads truetype truetype-fonts type1-fonts unicode vorbis xml xorg xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="i810" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I'd be very tempted to call this a 'feature' of sudo. I doubt there is anything we can really do about it; it's part of your job to ensure the correct resources for emerge to complete it's job. Emerge itself is written in python; I am unsure of a means (from within python) to remove ulimits. Emerge execs bash, and for the phases that run as root (which src_compile is not one of) we could strip ulimits in bash...but that doesn't cover all cases. I would be more concerned with the ulimit leakage from one user to another via sudo. I would honestly call it a bug; maybe the sudo upstream thinks differently though. -Alec
CCing sudo maintainer.
Behavior confirmed locally, suck :)
Based on this: http://www.gratisoft.us/pipermail/sudo-users/2004-July/002110.html The upstream thought on it is 'yeah, it's a bug, it's just really hard to do this in a way that works on all systems.' OTOH sudo already uses setrlimit to prevent core dumps, so I'm not sure why it wouldn't/couldn't do similar resets to set rlim_cur = rlim_max for RLIMIT_* The obvious workaround is to replace the /usr/bin/emerge symlink with a shell script that resets soft ulimits to their hard limit maximums and then execs /usr/lib/portage/bin/emerge so the entire portage system inherits those limits. I'm sure that suggestion will not fly on a global basis, but I suppose it will work for me in my environment.
Filed bug http://www.sudo.ws/bugs/show_bug.cgi?id=242 with sudo UPSTREAM.
