8

So no matter how many times I kill exim4 it immediately comes back to life. I have stopped the service and everything but something is bringing it back to life and using it for spamming.

How do I find who is the culprit, in other words, who is starting the exim process?

$ ps -ef | grep exim
root      3038     1  0 14:48 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5Mf-0000mt-L7
107       3042  3038  0 14:48 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5Mf-0000mt-L7
root      5083     1  0 14:49 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5N0-0001Jr-88
107       5233  5083  0 14:49 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5N0-0001Jr-88
root      7420     1  0 14:49 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5NR-0001vb-Km
107       7430  7420  0 14:49 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5NR-0001vb-Km
root      7454     1  0 14:49 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5NR-0001wA-Rl
107       7478  7454  0 14:49 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5NR-0001wA-Rl
root      7518     1  0 14:49 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5NS-0001xF-8C
107       7523  7518  0 14:49 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5NS-0001xF-8C
root      8863     1  0 14:50 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5Nm-0002Ir-93
107       8866  8863  0 14:50 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5Nm-0002Ir-93
root      8876     1  0 14:50 ?        00:00:00 /usr/sbin/exim4 -Mc 1YR5Nm-0002J5-Ee
5
  • you might try restricting the exim binary (take away execute), and then checking dmesg to see what app complains about it. Commented Feb 26, 2015 at 21:06
  • That's a great idea, Frank. How do I tail dmesg?
    – David Coch
    Commented Feb 26, 2015 at 21:21
  • depends on your system, but on my debian box, its sudo tail /var/log/dmesg . on ubuntu you can just say tail dmesg. and don't forget to check other logs. as well. the debug log may not get notified of that failure, but hopefully sys or messages does. Commented Feb 26, 2015 at 21:24
  • I am on UBUNTU. Checking /var/log/dmesg and /var/log/syslog but don't see anything there. Are you sure this permission error shows up there?
    – David Coch
    Commented Feb 26, 2015 at 21:35
  • like I said, not always. it is up to the developer to decide whether or not to write debug messages. instead check the sys/messages/auth logs, and see what you see. Commented Feb 26, 2015 at 21:36

1 Answer 1

11

A direct answer to your question (but not your problem) would be: ps -axjf. That's a and x to see "all" processes (see man page for a more elaborate explanation of these parameters), j for jobs format and f for the fancy ASCII art tree. The ppid (first column) shows the parent process ID.

A more direct approach to check the PPid of a specific process would be to check the PPid in /proc/<processid>/status, like this: grep PPid /proc/2774/status.

Now let's focus on your problem. With the information you provided, my guess is that you're trying to kill one of the mail delivery processes (in most configurations, exim spawns a separate process for each message to be delivered under user root). These processes use the -Mc option. From the Exim manual:

-MC <transport> <hostname> <sequence number> <message id>

This option is not intended for use by external callers. It is used internally by Exim to invoke another instance of itself to deliver a waiting message using an existing SMTP connection, which is passed as the standard input. This must be the final option, and the caller must be root or the Exim user in order to use it.

There is a queue runner process (often found in ps like: /usr/local/exim-in/bin/exim -bd -q 10m under user mail; not root). Probably that's the parent process. Note that exim often has more than one queue runner process. To inspect what's going on - process-wise - you can use the ps command mentioned earlier.

You might want to check what messages are queuing up in your mail queue (and why).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .