Re: [exim] Fatal: no entropy gathering module detected

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Bill Hacker
Datum:  
To: exim
Betreff: Re: [exim] Fatal: no entropy gathering module detected
Jeremiah Foster wrote:
> On Mon, 2006-01-16 at 03:51 +0800, Bill Hacker wrote:
>
>>Jeremiah Foster wrote:
>>
>>
>>>Hello,
>>>
>>>I am using exim4 and repeatedly get frozen messages. When I try to thaw
>>>them, I receive this error "Fatal: no entropy gathering module detected"
>
>
> *snip*
>
>
>>That's not enough information.
>>
>>Bill Hacker
>
>
> You're right, my apologies. My operating system is debian sarge, and I
> have posted this question on the debian exim4 mailing list but there is
> somewhat less traffic there.


Partly seasonal, I suspect. ;-)

There are a lot of (mostly?) Linuxen here, but Debian marches to a
different drumbeat than most other distros.

As IMHO, this is OS/installation specific/related, the Debian community
*will* be the best place to get appropriate guidance.
May need a bit of patience.

>The debian exim4 maintainer pointed me to a
> wiki entry http://wiki.debian.org/PkgExim4KnownBugsInSarge which has not
> helped resolve my particular issue.


BSD 'resolved' all that for me, years ago, but to each his own... ;-)

>
> my ps output shows four exim4 processes with two run by root and two by
> Debian-. Here is the output from ps -aux | grep exim


That would be 'most unusual' in an Exim+*BSD environment,
where one would see one process (minimum) when quiescent, at least one more
if/as/when a queue run and/or incoming connection is in process, plus
one more
per each additional active connection (mine have ranged up to ~ 170, but
3 to 8 is more common).

The default compile prevents running the daemon as root.

OTOH, Exim must be *initially called* by root, else cannot access any
port below 1024.
Exim drops root thereafter for an effective UID:GID specified in its
configuration file(s) (Debian's are unique).

Ownership in a *BSD would usually be mailnull:mail or such other
'custom' eximuser:eximgroup
as specified, such as exim:mail, or whatever.

'root' or a shell user would also appear if/as/when you had invoked, for
example, a debug/test run from the CLI, which are ordinarily ephemeral,
not daemonized processes, i.e. 'run once', so not all that easily observed.

IF your Exim has control of the SMTP port, it should also have, or have
had at one time, the ability to access the randomization and security
tools. This is what may be wrong - the manner of initial invocation.

Debian, as said, does things in its own way, but I would look at:

- From whence Exim is being 'started' or init'ed, and as what
user:group, and with what 'flags' or options.

- A conflict between whatever called/init'ed Exim and the runtime
configuration UID:GID.
That's in, for example, /usr/local/etc/exim/configure for a default
FreeBSD install, but 'somewhere else' for Debian.

- Unintended / attempted multiple invocation.

~/exim/paniclog and ~/exim/mainlog, and /var/log/messages (or the Debian
equivalents)
should be helpful.

If that doesn't reveal an obvious misconfiguration, you will need help
from Debian gurus.....

HTH,

Bill Hacker




>
> Debian-  29266  0.0  0.0  8692 2208 ?        Ss   17:42
> 0:00 /usr/sbin/exim4 -bd -q30m -oX 25:587 -oP /var/run/exim4/exim.pid
> root      4544  0.0  0.0  8560 2192 ?        S    20:12
> 0:00 /usr/sbin/exim4 -q
> root      5248  0.0  0.0  8600 2716 ?        S    20:12
> 0:00 /usr/sbin/exim4 -q
> Debian-   5312 98.7  0.0  8768 3064 ?        R    20:12
> 90:22 /usr/sbin/exim4 -q

>
> Regards,
>
> Jeremiah
>
>