Since a few days ago I noticed that /etc/ld.so.cache is regenerated upon every boot/reboot of my machine, even if it is not necessary, considerably slowing down startup time. I'm not sure which package upgrade caused this issue because that day I updated quite a lot of packages... Here it is the list: Fri Jun 15 12:51:20 2007 >>> sys-apps/portage-2.1.3_rc1 Fri Jun 15 12:55:59 2007 >>> app-arch/cpio-2.8 Fri Jun 15 12:57:09 2007 >>> sys-apps/findutils-4.3.7 Fri Jun 15 12:57:29 2007 >>> sys-apps/less-403 Fri Jun 15 12:58:00 2007 >>> sys-apps/man-pages-2.56 Fri Jun 15 12:58:36 2007 >>> sys-apps/diffutils-2.8.7-r2 Fri Jun 15 13:44:24 2007 >>> dev-lang/ruby-1.8.6_p36 Fri Jun 15 13:51:30 2007 >>> dev-util/subversion-1.4.4 Fri Jun 15 13:58:33 2007 >>> sys-apps/busybox-1.6.0 Fri Jun 15 13:58:38 2007 >>> sys-apps/hdparm-7.5 Fri Jun 15 13:59:04 2007 >>> media-libs/libexif-0.6.16 Fri Jun 15 14:04:58 2007 >>> dev-java/sun-jdk-1.5.0.12 Fri Jun 15 14:05:13 2007 >>> dev-perl/IO-Socket-SSL-1.07 Fri Jun 15 14:05:20 2007 >>> perl-core/libnet-1.21 Fri Jun 15 14:05:23 2007 >>> virtual/perl-libnet-1.21 Fri Jun 15 14:07:23 2007 >>> x11-wm/fluxbox-1.0_rc3-r493700 Fri Jun 15 14:14:58 2007 >>> app-text/ghostscript-gpl-8.57 Fri Jun 15 14:15:10 2007 >>> perl-core/File-Spec-3.25 Fri Jun 15 14:15:17 2007 >>> virtual/perl-File-Spec-3.25 Fri Jun 15 14:15:24 2007 >>> dev-perl/Archive-Zip-1.20 Fri Jun 15 14:16:58 2007 >>> sys-kernel/gentoo-sources-2.6.21-r3 Fri Jun 15 14:17:26 2007 >>> net-dialup/ppp-2.4.4-r8 Fri Jun 15 14:36:34 2007 >>> x11-libs/gtk+-2.10.13 Fri Jun 15 14:41:05 2007 >>> media-libs/xine-lib-1.1.7 Fri Jun 15 14:51:21 2007 >>> media-sound/amarok-1.4.6_pre20070608-r1 Fri Jun 15 14:52:51 2007 >>> gnome-base/librsvg-2.16.1-r2 Portage maybe? Reproducible: Always Steps to Reproduce: 1. Boot/reboot your machine 2. Wait ages for bootmisc init script to regenerate your /etc/ld.so.cache Actual Results: /etc/ld.so.cache is always regenerated Expected Results: /etc/ld.so.cache is regenerated only if really necessary emerge --info: Portage 2.1.3_rc4 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r3, 2.6.21-gentoo-r3-mactel x86_64) ================================================================= System uname: 2.6.21-gentoo-r3-mactel x86_64 Intel(R) Core(TM)2 CPU T7600 @ 2.33GHz Gentoo Base System release 2.0.0_alpha3 Timestamp of tree: Wed, 20 Jun 2007 22:20:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r7 sys-apps/sandbox: 1.2.18.1 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.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe" 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" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.unina.it/pub/linux/distributions/gentoo http://pandemonium.tiscali.de/pub/gentoo/" LANG="it_IT" LC_ALL="it_IT" LINGUAS="it" 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/portage/local/pesa" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X Xaw3d a52 aac acl acpi aim alsa amd64 avahi bash-completion bitmap-fonts blas bluetooth bzip2 cairo caps cddb cdparanoia cdr cli cracklib crypt curl curlwrappers dbus directfb dri dts dv dvd dvdr dvdread emboss encode evo exif expat fam fbcon ffmpeg fftw firefox flac ftp gd gdbm gif glut gmp gnutls gpm graphviz hal iconv icq idn ieee1394 imagemagick imlib ipod ipv6 isdnlog jabber java javascript jbig jpeg jpeg2k kde kdeenablefinal kdexdeltas lapack lcms libg++ libsamplerate lirc lm_sensors lua mad mailwrapper matroska midi mikmod mmap mmx mng mp3 mpeg mplayer msn mudflap musepack musicbrainz ncurses nls nptl nptlonly nsplugin offensive ogg opengl openmp oscar oss pam pcmcia pcre pdf perl plotutils png posix pppd python qt3 qt3support qt4 quicktime readline reflection ruby samba sasl sdl session slang sndfile snmp sockets socks5 speex spell spl sqlite sqlite3 sse sse2 ssl svg tcpd theora threads tiff truetype truetype-fonts type1-fonts unicode usb v4l vcd vorbis wifi wmf x264 xcomposite xine xinerama xml xorg xpm xv xvid zlib" ALSA_CARDS="hda-intel" 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 synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="it" LIRC_DEVICES="inputlirc sir" USERLAND="GNU" VIDEO_CARDS="fglrx radeon vesa fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
*** This bug has been marked as a duplicate of bug 161490 ***
Sorry Jakub, I cannot understand what this bug has in common with bug 161490, which is about ld.so.cache regeneration after an emerge -C, while I am speaking about an env-update run from init.d/bootmisc upon every boot, even if I don't unmerge any package...
What version of sys-apps/baselayout do you have?
as the init.d documents: ebegin "Updating environment" # As runscript prefixes our path with /$LIBDIR/rcscripts/bin, our # version instead of the portage version should be found first. env-update eend $? so it shouldnt be touching the portage one ...
(In reply to comment #3) > What version of sys-apps/baselayout do you have? > I have sys-apps/baselayout-2.0.0_alpha3, but I think this is more probably a baselayout-2 + portage-2.1.3 bug rather than a bug of baselayout-2 alone because I've been using baselayout-2 for several weeks now and there hasn't been any problem till the day I upgraded to portage-2.1.3_rc1...
as a test, could you do: which env-update in the /etc/init.d/bootmisc code just before env-update gets executed ? you could also do `env > /bootmisc.env` and post that file as an attachment
(In reply to comment #6) > as a test, could you do: > which env-update > > in the /etc/init.d/bootmisc code just before env-update gets executed ? you > could also do `env > /bootmisc.env` and post that file as an attachment > `which env-update` returns /sbin/env-update when executed from bootmisc init script and /usr/sbin/env-update when executed normally from a shell after booting. /sbin/env-update belongs to sys-apps/baselayout-2.0.0_alpha3-r1 /usr/sbin/env-update belongs to sys-apps/portage-2.1.3_rc4
Created attachment 122805 [details] Output of /usr/bin/env executed from bootmisc init script during boot
baselayout-2's env-update differs from baselayout-1 ... it runs ldconfig bootmisc should be updated to run env-update with --no-ldconfig or change the code so it tests to see if ld.so.conf actually changed ... also, in the case that it did change, we should prob add like a --fork-ldconfig option so that the ldconfig step forks into the background while the boot process continues on
(In reply to comment #9) > baselayout-2's env-update differs from baselayout-1 ... it runs ldconfig > > bootmisc should be updated to run env-update with --no-ldconfig or change the > code so it tests to see if ld.so.conf actually changed ... env-update does check to see if ld.so.conf changed or not - if so, it runs ldconfig. To verify this, see if the line "Regenerating /etc/ld.so.cache" is output during boot. If so, it's run ldconfig, if not then it's something else. Personally, I'm not seeing this. > also, in the case that it did change, we should prob add like a --fork-ldconfig > option so that the ldconfig step forks into the background while the boot > process continues on We have parallel startup for that.
i dont think parallel init.d is too applicable here ... the ld.so.cache can always be done in parallel to any other operation, no reason to make the default cause a huge drag at boot
I've committed a fix to our svn repo that adds the --fork-ldconfig option which the bootmisc initscript now uses.
