Re: [mlmmj] Errors on Cron job

Ben Schmidt <[email protected]>
Newsgroups org.mlmmj.mlmmj
Message-ID <[email protected]>
Hi, Barco,

Your permissions seem OK. Some questions and things to try:

- I trust you created your list with mlmmj-make-ml so it has all the necessary 
subdirectories, texts, etc. in the listdir?

- I can see your exim logs. If I remember correctly, Exim by default has its own 
log, e.g. /var/log/exim4.log or something. Have you checked syslog? Mlmmj's 
messages go to syslog, with the mail facility, so you might find its messages in 
/var/log/syslog or /var/log/mail.log or /var/log/mail.err or something like that. 
mlmmj-receive is clearly being executed and returning 1, which means it almost 
certainly will have logged a message. We just need to find it.

- Try removing the -F flag from the mlmmj-receive command and replacing it with a 
-P flag and send a test message. This tells mlmmj-receive not to try to process 
the message at all. When you send mail to the list then, it will deliberately not 
be processed, but we will know if it is failing earlier than that or not. See if 
it still returns 1 and you get a bounce message, or whether Exim thinks it has 
succeeded. See if your message appears in listdir/incoming; it should be left 
there if Mlmmj doesn't process it further.

- Are there other messages in listdir/incoming? Or listdir/queue or 
listdir/requeue or listdir/moderation or listdir/archive? What is the content of 
the listdir/index file, if it exists? Finding where in these folders your messages 
are, and what index it's up to, will give some insight into how much processing 
Mlmmj is succeeding to do.

- Try with neither the -F or -P flag and send a test message. That tells Mlmmj to 
operate as it does by default: it receives the message in the foreground, but 
attempts to process it in the background. I'm not sure why the Exim configuration 
doesn't use this mode, and it could be because Exim will kill the background 
process or something, but it might give some insight trying it anyway.

- Are there any special or unusual characters in your email address, list name, or 
domain at all?

- Is something (Exim? your shell?) running in a chroot environment, so actually 
things aren't where you expect them to be? Do you need to put the listdir, etc. 
inside a chroot jail somewhere for it to work?

- About the only time Mlmmj won't log an error but exit with failure is if the 
listdir isn't given on the commandline at all (it's missing -L). To be absolutely 
certain the correct command is being executed by Exim, you could rename 
mlmmj-receive to something else temporarily, and put a simple shell script there 
to log the commandline arguments, and send a test message. For example:

#!/bin/sh
echo "$@" > /tmp/mlmmj-args

Then look at /tmp/mlmmj-args after sending your test message and see what's there. 
I guess if the file doesn't appear where you expect, it's probably in a chroot 
jail somewhere.

Maybe one of these suggestions will help.

Smiles,

Ben



On 15/02/2017 12:41 am, Barco van Rhijn wrote:
>
> Ben, Thanks for your friendly reply.
>
> I have indeed copied the files to the /usr/bin directory. Usually this would 
> break other references in other programs. But I remembered after reading your 
> mail that MLMMJ has no dependencies.
>
> I've corrected some Permissions errors in the /var/spool/mlmmj/ directory. But I 
> still don't get any mail back from mlmmj even though the list does actually 
> receive it.
>
> The queue directory in the mailing list folder has several files in it. Which I 
> guess are some of the test messages I've sent.
>
>   * Since correcting the permissions I've not received any errors or messages
>     from the mlmmj-test group.
>   * Any idea how I could check why this is not being processed?
>
> Barco
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Here's more information on the Troubleshooting process up to this point:
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> I'm still getting this nagging thing with the mail. I've tested my Exim config 
> as suggested in the mlmmj-exim readme files.
> And everything checks out nicely. Email does in fact get routed to MLMMJ's spool 
> directory.
>
> But I get an error message back when I post to the list:
>
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>    [email protected]
>      local delivery failed
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> BTW - My email address and the mlmmj group are on the same server
>
> *Checking the logs I found:*
>
> P=esmtpsa X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no 
> A=dovecot_plain:[email protected] S=810 
> [email protected] T="Hello world" for 
> [email protected]
> 2017-02-14 12:43:18 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1cdaZp-00044A-GZ
> 2017-02-14 12:43:19 1cdaZp-00044A-GZ ** [email protected] 
> R=mlmmj_router */T=mlmmj_transport: Child process of mlmmj_transport transport 
> returned 1 from command/*: */usr/local/bin/mlmmj-receive*
> 2017-02-14 12:43:19 cwd=/var/spool/exim 7 args: /usr/sbin/exim -t -oem -oi -f <> 
> -E1cdaZp-00044A-GZ
> 2017-02-14 12:43:19 SMTP connection from xxx.xxx.x.x closed by QUIT
> 2017-02-14 12:43:19 1cdaZr-00044T-1p <= <> R=1cdaZp-00044A-GZ U=mailnull P=local 
> S=2078 T="Mail delivery failed: returning message to sender" for 
> [email protected]
> 2017-02-14 12:43:19 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc 1cdaZr-00044T-1p
> 2017-02-14 12:43:19 1cdaZp-00044A-GZ Completed
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> *From my digging into this on the mlmmj mailing-list archives it appears to be 
> permission related. *
>
> I found some files and folders in the /var/spool/mlmmj directory did not have 
> the permissions specified.
>
> -- Setting permissions.
>
> *I've checked my /var/spool/mlmmj directory and all files and lists under this 
> have the following permissions:*
>
> mlmmj mlmmj 755
>
> *I've also changed the permissions of all the mlmmj files in /usr/local/bin/*
>
> mlmmj mlmmj 755
>
> *After checking this* *when I run the Maintenance Script (/usr/bin/mlmmj-maintd 
> -F -L)**
> **I get:*
>
> **reply from quit: 250 OK
>
> reply from quit: 250 OK
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> *Output of the operation log*
>
> Tue Feb 14 12:51:46 2017 mlmmj-process: access - A mail from 
> "[email protected]" was allowed by rule #0 "allow"
> Tue Feb 14 12:57:19 2017 mlmmj-process: access - A mail from 
> "[email protected]" was allowed by rule #0 "allow"
> Tue Feb 14 13:09:12 2017 mlmmj-process: access - A mail from 
> "[email protected]" was allowed by rule #0 "allow"
> Tue Feb 14 15:06:50 2017 mlmmj-process: access - A mail from 
> "[email protected]" was allowed by rule #0 "allow"
>
> *Output of mlmmj-maint.d lastrun.log*
>
> Starting maintenance run at Tue Feb 14 15:10:55 2017
>
> clean_moderation(/var/spool/mlmmj/mlmmj-test);
> clean_discarded(/var/spool/mlmmj/mlmmj-test);
> clean_subconf(/var/spool/mlmmj/mlmmj-test);
> clean_unsubconf(/var/spool/mlmmj/mlmmj-test);
> resend_queue(/var/spool/mlmmj/mlmmj-test, /usr/bin/mlmmj-send);
> resend_requeue(/var/spool/mlmmj/mlmmj-test, /usr/bin/mlmmj-send);
> clean_nolongerbouncing(/var/spool/mlmmj/mlmmj-test);
> unsub_bouncers(/var/spool/mlmmj/mlmmj-test, /usr/bin/mlmmj-unsub);
> probe_bouncers(/var/spool/mlmmj/mlmmj-test, /usr/bin/mlmmj-bounce);
> run_digests(/var/spool/mlmmj/mlmmj-test, /usr/bin/mlmmj-send);
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>

Hi, Barco,

Your permissions seem OK. Some questions and things to try:

- I trust you created your list with mlmmj-make-ml so it has all
the necessary subdirectories, texts, etc. in the listdir?

- I can see your exim logs. If I remember correctly, Exim by
default has its own log, e.g. /var/log/exim4.log or something.
Have you checked syslog? Mlmmj's messages go to syslog, with the
mail facility, so you might find its messages in /var/log/syslog
or /var/log/mail.log or /var/log/mail.err or something like that.
mlmmj-receive is clearly being executed and returning 1, which
means it almost certainly will have logged a message. We just need
to find it.

- Try removing the -F flag from the mlmmj-receive command and
replacing it with a -P flag and send a test message. This tells
mlmmj-receive not to try to process the message at all. When you
send mail to the list then, it will deliberately not be processed,
but we will know if it is failing earlier than that or not. See if
it still returns 1 and you get a bounce message, or whether Exim
thinks it has succeeded. See if your message appears in
listdir/incoming; it should be left there if Mlmmj doesn't process
it further.

- Are there other messages in listdir/incoming? Or listdir/queue
or listdir/requeue or listdir/moderation or listdir/archive? What
is the content of the listdir/index file, if it exists? Finding
where in these folders your messages are, and what index it's up
to, will give some insight into how much processing Mlmmj is
succeeding to do.

- Try with neither the -F or -P flag and send a test message.
That tells Mlmmj to operate as it does by default: it receives the
message in the foreground, but attempts to process it in the
background. I'm not sure why the Exim configuration doesn't use
this mode, and it could be because Exim will kill the background
process or something, but it might give some insight trying it
anyway.

- Are there any special or unusual characters in your email
address, list name, or domain at all?

- Is something (Exim? your shell?) running in a chroot
environment, so actually things aren't where you expect them to
be? Do you need to put the listdir, etc. inside a chroot jail
somewhere for it to work?

- About the only time Mlmmj won't log an error but exit with
failure is if the listdir isn't given on the commandline at all
(it's missing -L). To be absolutely certain the correct command is
being executed by Exim, you could rename mlmmj-receive to
something else temporarily, and put a simple shell script there to
log the commandline arguments, and send a test message. For
example:

#!/bin/sh

echo "$@" > /tmp/mlmmj-args

Then look at /tmp/mlmmj-args after sending your test message and
see what's there. I guess if the file doesn't appear where you
expect, it's probably in a chroot jail somewhere.

Maybe one of these suggestions will help.

Smiles,

Ben

On 15/02/2017 12:41 am, Barco van Rhijn
wrote:

Ben, Thanks for your friendly reply.

I have indeed copied the files to the /usr/bin directory.
Usually this would break other references in other programs. But
I remembered after reading your mail that MLMMJ has no
dependencies.

I've corrected some Permissions errors in the /var/spool/mlmmj/
directory. But I still don't get any mail back from mlmmj even
though the list does actually receive it.

The queue directory in the mailing list folder has several
files in it. Which I guess are some of the test messages I've
sent.

- Since correcting the permissions I've not received any
errors or messages from the mlmmj-test group.

- Any idea how I could check why this is not being processed?

Barco

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Here's more information on the Troubleshooting process up to
this point:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

I'm still getting this nagging thing with the mail. I've tested
my Exim config as suggested in the mlmmj-exim readme files.

And everything checks out nicely. Email does in fact get routed
to MLMMJ's spool directory.

But I get an error message back when I post to the list:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

[email protected]
local delivery failed

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

BTW - My email address and the mlmmj group are on the same
server

Checking the logs I found:

P=esmtpsa X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no A=dovecot_plain:[email protected]
S=810 [email protected]
T="Hello world" for [email protected]

2017-02-14 12:43:18 cwd=/var/spool/exim 3 args: /usr/sbin/exim
-Mc 1cdaZp-00044A-GZ

2017-02-14 12:43:19 1cdaZp-00044A-GZ ** [email protected]
R=mlmmj_router T=mlmmj_transport: Child process of
mlmmj_transport transport returned 1 from command:
/usr/local/bin/mlmmj-receive

2017-02-14 12:43:19 cwd=/var/spool/exim 7 args: /usr/sbin/exim
-t -oem -oi -f <> -E1cdaZp-00044A-GZ

2017-02-14 12:43:19 SMTP connection from xxx.xxx.x.x closed by
QUIT

2017-02-14 12:43:19 1cdaZr-00044T-1p <= <>
R=1cdaZp-00044A-GZ U=mailnull P=local S=2078 T="Mail delivery
failed: returning message to sender" for [email protected]

2017-02-14 12:43:19 cwd=/var/spool/exim 3 args: /usr/sbin/exim
-Mc 1cdaZr-00044T-1p

2017-02-14 12:43:19 1cdaZp-00044A-GZ Completed

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

From my digging into this on the mlmmj
mailing-list archives it appears to be permission related.

I found some files and folders in the /var/spool/mlmmj
directory did not have the permissions specified.

-- Setting permissions.

I've checked my /var/spool/mlmmj directory and all files and
lists under this have the following permissions:

mlmmj mlmmj 755

I've also changed the permissions of all the mlmmj files in
/usr/local/bin/

mlmmj mlmmj 755

After checking this when I run the Maintenance
Script (/usr/bin/mlmmj-maintd -F -L)

I get:

reply from quit: 250 OK

reply from quit: 250 OK

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Output of the operation log

Tue Feb 14 12:51:46 2017 mlmmj-process: access - A mail from "[email protected]"
was allowed by rule #0 "allow"

Tue Feb 14 12:57:19 2017 mlmmj-process: access - A mail from "[email protected]"
was allowed by rule #0 "allow"

Tue Feb 14 13:09:12 2017 mlmmj-process: access - A mail from "[email protected]"
was allowed by rule #0 "allow"

Tue Feb 14 15:06:50 2017 mlmmj-process: access - A mail from "[email protected]"
was allowed by rule #0 "allow"

Output of mlmmj-maint.d lastrun.log

Starting maintenance run at Tue Feb 14 15:10:55 2017

clean_moderation(/var/spool/mlmmj/mlmmj-test);

clean_discarded(/var/spool/mlmmj/mlmmj-test);

clean_subconf(/var/spool/mlmmj/mlmmj-test);

clean_unsubconf(/var/spool/mlmmj/mlmmj-test);

resend_queue(/var/spool/mlmmj/mlmmj-test, /usr/bin/mlmmj-send);

resend_requeue(/var/spool/mlmmj/mlmmj-test,
/usr/bin/mlmmj-send);

clean_nolongerbouncing(/var/spool/mlmmj/mlmmj-test);

unsub_bouncers(/var/spool/mlmmj/mlmmj-test,
/usr/bin/mlmmj-unsub);

probe_bouncers(/var/spool/mlmmj/mlmmj-test,
/usr/bin/mlmmj-bounce);

run_digests(/var/spool/mlmmj/mlmmj-test, /usr/bin/mlmmj-send);

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.