Apache Wakes-up Inactive Exim

Home » CentOS » Apache Wakes-up Inactive Exim
CentOS 20 Comments

Had a surprising event on C 6.5.

Exim was the only MTA installed. It was partially configured (with ACL, Router, Transport) and definitely not running.

I was remotely testing a web page. A web page error condition invoked the embedded PHP mail() command.

To my astonishment something in CentOS woke-up Exim. Exim sent the email and then became inactive again. The Exim logs does not show any start-up lines, just

1. input from Apache.
2. output to remote server.
3. ‘completed’.

Hours later Logwatch, not yet customised, also caused inactive Exim to send an email (which got rejected by Exim because it was to local user

What causes CentOS to temporarily activate in-active (meaning non-running) Exim ?


Paul. England EU.

20 thoughts on - Apache Wakes-up Inactive Exim

  • You don’t really need an active SMTP daemon to send email or deliver it locally.
    $ cat /etc/php.ini | grep sendmail

  • The daemon only handles incoming mail, or in other words waits for incoming connections from other mail servers. Outgoing mail is sent on demand, or in other words a connection is made to a mail server or relay as and when required.



  • Applications often send mail by piping to the command ‘sendmail’ which is enough of a standard that other MTAs normally offer a compatible command. With ‘real’ sendmail you can configure it to either deliver in the current process or to queue for subsequent delivery by the daemon. Not sure how the others handle it, but yours apparently completes the delivery.

  • “Package(s) sendmail available, but not installed.”

    It was Exim because the email headers said very clearly it was Exim.


    Paul. England, EU.

  • Sendmail is not present on the server. Exim is the only MTA. Exim awoke, forwarded the email then became inactive (not running) again.

    I was curious how a non-running Exim can be run, solely to forward mail, then returned to its inactive state. I assume some system software identified the PHP outgoing email, and launched the only MTA installed
    (Exim) just to handle the outgoing email.

  • He didn’t say sendmail the package was present; he said sendmail the command.

    rpm -qvl exim | grep sendmail

    Those targets are used by the alternatives system and provide backwards compatibility with the _industry standard_ of /usr/sbin/sendmail and
    /usr/lib/sendmail, which are expected interfaces.

    exim sends mail by default; nothing needs to be running to do so.


  • Ubuntu).

    cliffp@ubuntu:~$ which sendmail
    /usr/sbin/sendmail cliffp@ubuntu:~$ file `which sendmail`
    /usr/sbin/sendmail: symbolic link to `exim4′



  • C 5.10 & C 6.5

    file `which sendmail`

    /usr/sbin/sendmail: symbolic link to `/etc/alternatives/mta’

    strings /etc/alternatives/mta |grep exim

    produces Exim lines. No results for Postfix or for Sendmail.

    Thanks. I learned something new today.

    Paul. England, EU.

  • Not exactly… Applications that pipe to the sendmail command line program to send messages go back to the dawn of email. MTAs that replace the ‘real’ sendmail pretty much have to provide that functionality.

  • Yes I did learn something new.

    I started to use Linux, CentOS, in desperation to rid myself of Windoze. I plunged-in, never learned the theory because of inadequate time. Hence I am Always Learning and never falling to be impressed, continuously delighted to be rid of M$ and wishing I have ventured into Linux 10+
    years earlier than I did.

  • Always Learning wrote:

    A *very* strong recommendation: find a copy of Frisch’s Essential Systems Administration, published by O’Reilly. Some of it’s out of date, some more Unix than Linux… but read chapter 2, “The Unix Way”. A *lot* will be a lot clearer.

    mark “been shoving this at people for > 15 years”

  • Just new to you…

    If you really want to appreciate the concepts, you should find a unix manual from the days before X was included. Back then there were 5
    sections where 1 covered the command line programs, 2 covered system calls, 3 the standard C library, etc. It was small enough that you could read and mostly memorize it, especially section 1, in a few days. The thing to appreciate is that 30+ years later, even in cloned versions, those things were designed well enough that pretty much everything in there still continues to work.

  • Its the time required to read non-essential items. Too many important demands on my time and too much work to do.

    Might try at Christmas if fewer demands on my time and energy.

    Thanks for the tip.

  • Sigh… I’m rarely convinced that “how you _should_ do something”
    should change just because some programmer that didn’t understand the old, working way wrote something new and buggy.

    Les Mikesell

  • No. Not only to me but also new to others who, like me, never knew. Learning is a continuous process :-)

    Design is so important. Get it really right the first time and vast amounts of time and effort are saved. If I ever encounter a Unix book or manual, I’ll certainly keep it to read.

    Thank you.

    Paul. England, EU.

  • Always Learning wrote:
    time. continuously date, some will be a

    I’m just pushing one chapter at you.

    I got into systems administration back in the mid-nineties. Two weeks after I was hired for a startup division of a huge telecom (a Baby Bell), I was asked if I wanted to pick up systems admin from one of the consultants, who’d be rolling off. I said, sure….

    Almost a year later, when the division had grown from 4 groups to 27(!), and they brought in the corporate sysadmins, I got friendly with them, and kept doing most of the work on the server our teams under our director used. They told me of all the servers, *two* (count them) looked normal
    (as opposed to everyone having the root password, files and directories all over the place, etc, etc), and mine was one… and that was because I’d been sleeping with Frisch’s book, as well as my …late… wife.

    *Make* the time. It’ll save your bacon.


  • There is plenty of documentation around now, but it is much, much harder to sort out the core tools from the cruft and specialty stuff now. If you understand what the fork() system call does, most of the rest of what unix-like systems do will generally make sense.

  • Always Learning wrote:

    Yup – British bacon may well be better than American (even when you can get American bacon that’s not 75% or more fat)….