See the above forum URL for a somewhat cleaner explanation. Openssl is using up a lot of cpu. It seems to be caused by the cron job qmail installs. /usr/bin/openssl genrsa -out ${tmpfile} ${bits} 2>/dev/null Running thge command manually takes .10'ths of a second, but when it is run by cron, the job seems to take "forever" (a few minutes at least on my AMD 2500+). Several other people are experiencing the same problem. There's no real common CFLAG which seems to be causing this. Reproducible: Always Steps to Reproduce: Medusa% emerge info Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-4.0.1, glibc-2.3.5-r0, 2.6.12-nitro5 i686) ================================================================= System uname: 2.6.12-nitro5 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.6.13 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -mmmx -msse -m3dnow -mfpmath=sse,387 -ffast-math" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/fax /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/alias /var/qmail/control /var/spool/fax/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer -mmmx -msse -m3dnow -mfpmath=sse,387 -ffast-math" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://gd.tuwien.ac.at/opsys/linux/gentoo/ ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo" LANG="nl_NL@euro" LC_ALL="nl_NL@euro" LDFLAGS="-Wl,-O9 -Wl,--enable-new-dtags -Wl,--sort-common -s -Wl,--as-needed" LINGUAS="nl" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex 3dnowext X aalib alsa apache2 apm arts audiofile avi bash-completion bitmap-fonts bonobo browserplugin bzip2 bzlib calender cdparanoia cdr chipcard chm chroot crypt cups curl dba divx4linux dlloader dvd dvdr dvdread eds emboss encode esd fam festival ffmpeg filepro firefox flac flatfile font-server foomaticdb fortran ftp gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 guile hal imagemagick imap imlib insecure-drivers java jpeg jpeg2k junit kde kdgraphics kqemu ldap libg++ libwww live logitech-mouse mad matroska mikmod mime mmx mmxext mono motif mozdevelop mozilla moznomail moznoxft mp3 mpeg mplayer msn mysql ncurses network nls nptl nvidia odbc offensive ogg oggvorbis ooo-kde opengl pam patches pdflib perl php pic png postgres python qmail qt quicktime rar readline real rplay samba scanner sdk sdl session sftplogging slang softmmu speex spell sqlite sse ssl startup-notification stroke subtitles svga tcltk tcpd theora threads tiff truetype truetype-fonts type1-fonts unicode usb userlocales v4l v4l2 vorbis webservices win32codecs wmf xine xinerama xml xml2 xmms xprint xscreensaver xv xvid zlib video_cards_nvidia linguas_nl userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET
I noticed that long term >90% openssl cpu usage on a server, too. Could that issue be related to the infamous "lack of entropy from /dev/random" topic? That could explain that the command has no problems when executed manually, as the keystrokes from typing it in may already have created a sufficient amount of entropy ;-) Perhaps someone can look into that cron job to make it use /dev/urandom. That device will provide "pseudo" random values in case there is not enough "real" entropy (instead of blocking like /dev/random does).
No, tried adding "-rand /dev/urandom" to the openssl calls in /etc/cron.hourly/qmail-genrsacert.sh but they seem to make no difference. Maybe OpenSSL uses /dev/urandom by default already? But if you run "time sh -x /etc/cron.hourly/qmail-genrsacert.sh" you will be able to see where it spends its time. The whole thing typically takes about 2-3 minutes here (and uses >90% CPU during that time. Ok, quite an old PII@450 MHz). The most time seems to be taken by the "openssl dhparam" calls. According to http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102646106016694 there once was a "slow dhparam" problem on HP-UX (but seems somewhat PA-RISC 64bit specific). But perhaps hdparam *is* that complex / slow? In this case, is it really neccassary to run that job every hour, or would it be sufficient to do that once a day?
Ok, manually executing "time /usr/bin/openssl dhparam -2 -out /dev/null 1024" takes between 2 and 5(!) minutes here. But "time /usr/bin/openssl dhparam -dsaparam -out /dev/null 1024" always finishes in < 10 seconds. Given the fact the "-dsaparam" is said to be "weaker" according to the man page, could it still be useable / sufficient for the purpose of qmail?
Re-assign.
I'm having this problem too, on my desktop system. It's an 850MHz system so you definitely notice when something takes over the whole CPU for ~10 minutes every hour. I do run qmail, but only so that my small handful of cron-jobs can send their output to my real (non-local) email account. And I don't (to my knowledge) have any kind of encryption enabled for my mail, nor is any of it particularly sensitive, so I'm not sure why I even need these certificates at all? I noticed that I actually have two different copies of this qmail-genrsacert.sh script installed: one in /etc/cron.daily which is version 1.2 of the script, and the second in /etc/cron.hourly which is version 1.4. Since I'm not even convinced that I need this script at all, I'm just going to delete the old version from cron.daily and then move the new version from hourly to daily. I can deal with such a slowdown once per day, but not once per hour.
USE="gencertdaily" You need the script if you want to connect to another host using SSL.
Thank you! Is this a new USE flag, or has it been there all the time? Does USE=-gencertdaily make qmail generate it every hour, or not at all? Changing to test-request
The use flag has been there since a few weeks before -r16 went stable. USE=-gencertdaily generates them hourly.
