We've been experiencing pain due to the daily STunnel regeneration of the DH Parameters. On our single-core machines in the field, this process will use 100% of the CPU for possibly an extended time. This interferes with other tasks that the machine is intended for. What's odd is that this process time ranges wildly, ranging from as low as 3 seconds to 90 minutes, even on the same machine. We see this behavior on all (thousands) of our machines, now that we know what to look for (the "Cron jobs completed in" trace in stunnel.log).
We now know that we can set the DH Parameters in the configuration file, and that's what we'll be doing going forward. (Unless someone has another idea to offer.)
I'd like to suggest some ideas for the future since I've seen on the mailing list that there are others who have run into this issue:
* If the DH Parameter regeneration would run at Idle priority instead of Normal priority, it would not be nearly as noticeable, in that the CPU usage would still be there, but it wouldn't impact other services. The recomputation may be done in a separate thread, if so, this is straight-forward.
* If there were a configuration file parameter to specify the regeneration interval. It would default to 24 hours (which is the current behavior), but could be set to a longer interval, a shorter interval for extreme security, or even to never. STunnel would still regenerate at the time of the service starting, unless a fixed DH is found in the configuration file. If a fixed DH were specified in the configuration file, that would avoid the service start computation and the interval would default to never. If both a fixed DH and the interval were specified in the configuration file, it would use the specified interval and recompute only after that interval.