Summary: | qmail cron job which uses openssl is causing high cpu usage for a large amount of time | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Roel Brook <Rainmaker526> |
Component: | Current packages | Assignee: | Qmail Team (OBSOLETE) <qmail-bugs+disabled> |
Status: | VERIFIED TEST-REQUEST | ||
Severity: | normal | CC: | aliz, gentoo, mail, schnake.newsletter, theant |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic.php?p=2652189 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Roel Brook
2005-08-15 17:40:08 UTC
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. |