procmail is not executing scripts correctly

ChrisInAlpharetta · 04-21-2011, 07:08 AM

I'm having a strange issue with running scripts (perl and ruby failing) from incoming mail locally delivered by procmail.

The system is CentOS 5.5 with postfix as my mailer, then a .forward set up to send email on to procmail. The .procmailrc and scripts are identical to a working setup on an Ubuntu server.

Here's the .procmailrc:

Code:

PATH= /usr/local/bin:/usr/bin:${PATH}
SHELL=/bin/bash
MAILDIR=$HOME/Maildir
DEFAULT=${MAILDIR}/
LOGABSTRACT=yes
LOGFILE=$HOME/Maildir/proclog
VERBOSE=YES

:0 wc
* ^To.*web@mydomain.com
| /home/web/perltest.pl

Here's the perl script:

Code:

#!/usr/bin/env perl

system("touch /home/web/touchedfile");

And then the failure in the log upon receiving email:

Code:

procmail: Executing "/home/web/perltest.pl"
/home/web/perltest.pl: line 3: syntax error near unexpected token `"touch /home/web/touchedfile"'
/home/web/perltest.pl: line 3: `system("touch /home/web/touchedfile");'

The line endings are all UNIX. The script runs fine from the command line.

The whole setup works fine if I pipe to procmail directly from the command line, but when it's invoked as part of the local delivery process, the #! line seems to be ignored in the script.

I can get the perl script to run if I explicitly execute perl in the pipe, like so:

Code:

:0 wc
* ^To.*web@mydomain.com
| perl /home/web/perltest.pl

... but I really don't want to admit defeat and do that.

bathory · 04-21-2011, 08:41 AM

Hi,

You need to give the full path to the command touch in your perl script:

Code:

#!/usr/bin/env perl

system("/usr/bin/touch /home/web/touchedfile");

Regards

ChrisInAlpharetta · 04-21-2011, 11:27 AM

Quote:

Originally Posted by bathory

Hi,

You need to give the full path to the command touch in your perl script:

No, it's not an issue of the Perl script itself. If you look at the error message, the Perl executable isn't even being called. Instead, the sh (bash) parser is choking on the perl code.

Normally, something like this is the result of line ending problems (DOS, usually) so where the #! line isn't parsed correctly by the shell and the sh interpreter assumes that the file is a valid shell script.

As I mentioned, the line endings are correct. The file is executed properly if I put "|perl /home/web/perltest.pl" in the procmail. For some reason, though, the #! line is being ignored.

(Also worth noting that lots of other scripts I have don't work either when executed from this procmail pipe. They always fail to parse on the first line of the script, whether it's perl or ruby)

bathory · 04-21-2011, 12:44 PM

FYI I've tried to run the script through procmail and got the same error, until I used the full path to the touch command.
So I guess it's worth trying it...

ChrisInAlpharetta · 04-21-2011, 01:26 PM

Quote:

Originally Posted by bathory

FYI I've tried to run the script through procmail and got the same error, until I used the full path to the touch command.
So I guess it's worth trying it...

Nah. Didn't work. I also tried getting rid of calling any external executables by using only Perl's API:

Code:

my $file = '/home/web/touchedfile';
open(FILE, ">$file") or die "Couldn't open file";
print FILE "ARGS: ", join(', ', @ARGV), "\n";
close FILE;

This didn't work either:

Code:

procmail: Executing "/home/web/perltest.pl"
/home/web/perltest.pl: line 3: my: command not found
/home/web/perltest.pl: line 4: syntax error near unexpected token `FILE,'
/home/web/perltest.pl: line 4: `open(FILE, ">$file") or die "Couldn't open file";'

The fact that the "my" wasn't even parsed is a sure sign that the Perl interpreter isn't engaged.

bathory · 04-22-2011, 04:19 AM

Hi,

Since it works for me (on Slackware) and for you on Ubuntu, but not on Centos, it could be SELinux.

ChrisInAlpharetta · 04-22-2011, 01:44 PM

Quote:

Originally Posted by bathory

Hi,

Since it works for me (on Slackware) and for you on Ubuntu, but not on Centos, it could be SELinux.

Yes, indeed. SELinux was the problem. That was a very confusing problem that was complicated by some VM environment uncertainty that I had.

I'll definitely remember to think "SELinux" the next time something mysterious is happening.