Facebook
Twitter- Server operating system version
- AlmaLinux 8
- Plesk version and microupdate number
- 18.0.55 Update 2
Any ideas what might have changed the behaviour of Sendmail invoked via Postfix on 18.0.55 Update 1, we are seeing unexpected error messages in the mail logs.
We have a custom script invoked by Postfix (spamchk) which checks for the X-Spam-Status heading added by SpamAssassin and discards the email if present:
SENDMAIL=/usr/sbin/sendmail
EGREP=/usr/bin/egrep
cat | /usr/bin/spamc -u spamfilter | sed 's/^\.$/../' > /var/tempfs/out.$$
if $EGREP -q "^X-Spam-Status: Yes" < /var/tempfs/out.$$
then
exit 0
else
Otherwise it send the email on as follows:
$SENDMAIL "$@" < /var/tempfs/out.$$
exit 0
fi
This stopped working after the Update 1 install and now we see errors like this in the mail logs:
Sep 28 12:35:53 servername plesk-sendmail[1452134]: S1452134: cannot create temporary file - (30) Read-only file system
Sep 28 12:35:53 servername plesk-sendmail[1452134]: S1452134: Unable to save stdin content to temporary file
Running sendmail on CLI sends these same messages fine (as long as the user has a shell). The user spamfilter has a bash shell but that makes no difference to the script which has been in use for around 8 years on multiple CentOS servers (previously without Plesk).
We assumed file / folder permissions might be to blame, but even with a 777 setup trying to access a know file this still fails when run in the spamchk script from Postfix (with hardcoded destination email and filename, ruling out the possibility that the parameters in the script above may be incorrect):
Sep 28 09:47:32 servername postfix/pipe[1422106]: 7B0D81960DFB: to=<recipient@x.y.z>, orig_to=<email@x.y.z>, relay=spamchk, delay=0.31, delays=0.15/0/0/0.16, dsn=2.0.0, status=sent (delivered via spamchk service (plesk-sendmail[1422664]: S1422664: cannot create temporary file - (30) Read-only file system plesk-s))
and
(/usr/local/bin/spamchk: line 28: /tmp/mail.txt: No such file or directory plesk-sendmail[1452951]: S))
The Postfix install is a custom one from the OS vendor, not controlled / updated by Plesk. There are some suggestions that this can have side-effects. (That was done to get support for PostGres mail forwarding tables)
We have a custom script invoked by Postfix (spamchk) which checks for the X-Spam-Status heading added by SpamAssassin and discards the email if present:
SENDMAIL=/usr/sbin/sendmail
EGREP=/usr/bin/egrep
cat | /usr/bin/spamc -u spamfilter | sed 's/^\.$/../' > /var/tempfs/out.$$
if $EGREP -q "^X-Spam-Status: Yes" < /var/tempfs/out.$$
then
exit 0
else
Otherwise it send the email on as follows:
$SENDMAIL "$@" < /var/tempfs/out.$$
exit 0
fi
This stopped working after the Update 1 install and now we see errors like this in the mail logs:
Sep 28 12:35:53 servername plesk-sendmail[1452134]: S1452134: cannot create temporary file - (30) Read-only file system
Sep 28 12:35:53 servername plesk-sendmail[1452134]: S1452134: Unable to save stdin content to temporary file
Running sendmail on CLI sends these same messages fine (as long as the user has a shell). The user spamfilter has a bash shell but that makes no difference to the script which has been in use for around 8 years on multiple CentOS servers (previously without Plesk).
We assumed file / folder permissions might be to blame, but even with a 777 setup trying to access a know file this still fails when run in the spamchk script from Postfix (with hardcoded destination email and filename, ruling out the possibility that the parameters in the script above may be incorrect):
Sep 28 09:47:32 servername postfix/pipe[1422106]: 7B0D81960DFB: to=<recipient@x.y.z>, orig_to=<email@x.y.z>, relay=spamchk, delay=0.31, delays=0.15/0/0/0.16, dsn=2.0.0, status=sent (delivered via spamchk service (plesk-sendmail[1422664]: S1422664: cannot create temporary file - (30) Read-only file system plesk-s))
and
(/usr/local/bin/spamchk: line 28: /tmp/mail.txt: No such file or directory plesk-sendmail[1452951]: S))
The Postfix install is a custom one from the OS vendor, not controlled / updated by Plesk. There are some suggestions that this can have side-effects. (That was done to get support for PostGres mail forwarding tables)
