I would guess that something is going wrong at the .configure point -- that it is not happening on subsequent re-installs, or that the file it is looking for (qmail-queue.orig) is getting overwritten in some way (e.g. the qmail-scanner version becomes the .orig version which is wrong) or something along those lines.

I'm guessing all this because if qmail-scanner does not uninstall cleanly, then on re-install is does not have the right environment to install in.

If I knew anything about .spec files or whatever it is that contains the install and uninstall scripts, I'd be expecting to see qmail-queue.orig NOT being correctly copied back to qmail-queue .... or something.

Having said all this, I rather doubt I'm anywhere close to being correct as otherwise someone would have seen this a long time ago.

I also doubt I understand how the darned thing works. It seems unlikely that the script is somehow taking a binary file, then patching it with the qmail-queue source-code patch?

Actually I've seen those 4PSA products break a couple of times after installing Plesk micro updates, even recently. Removing and re-adding the cserver/sguardian mail handlers fixes those problems.

As far as I know qmail-scanner does not use Plesk's mail handler system, but just replaces /var/qmail/bin/qmail-queue to insert itself into the chain.

I am having a rough time in all of this. I am new to Plesk, generally I use cpanel or no panel. I am really having a rough time. I have run through the steps above but am not having any love. Neither Postfix or qmail is working. I got one email to come in once time after an RPM force install of the psa qmail.

See link here:

http://forum.parallels.com/showthread.p ... post623303

Any help for a new guy would be appreciated.

UPDATE: SOLVED

I found the reason of the issue, mail handlers could not create temporary file in directory /usr/local/psa/handlers/spool
In order to fix it I have changed permissions on directory /usr/local/psa/handlers/spool to 770 as it was set on our test server:

CODE Below:

[root@********** bin]# chmod 770 /usr/local/psa/handlers/spool
[root@********** bin]# ls -lda /usr/local/psa/handlers/spool
drwxrwx--- 2 popuser popuser 4096 May 2 21:43 /usr/local/psa/handlers/spool

Well, MU#29 is out. Anybody tried it? Did it kill qmail-scanner again?

Oddly, there's no mention of #29 in the changelog so I don't know what's in it. Only #28 is mentioned.

Yes.



No.



See here: http://kb.parallels.com/en/113825

Thanks Breun. So #28 killed it, but #29 didn't? Interesting.

However, I note that some users are having generic qmail problems after installing #29

http://forum.parallels.com/showthread.php?t=259380

The solution appears to be to run: restorecon /usr/local/psa/handlers/hooks/check-quota

Please note: The above command is not meant to fix qmail-scanner. It has nothing to do with qmail-scanner. It resolves a problem with qmail nor accepting email after installing MU#29 under some circumstances and I'm mentioning it here for posterity as we are discussing MU#29 and qmail here too.

All this goes to show that allowing plesk to update itself via MUs is not the best idea really.

If a micro update doesn't do anything mail related it also won't break anything mail related. Doesn't sound too strange to me.



restorecon is a SELinux-related command. I guess most people here are not using SELinux (ASL doesn't use it).



I'd say not updating and not fixing bugs is not the best idea either. All this goes to show that testing updates on your setup is important.

This is strange!

I've been putting off the MUs -- didn't want to go through the qmail dance from MU#28 until I had time to deal with it. So when MU#30 came out with a fix for the Horde issue and I had time to spare, I went ahead and updated, then sshed in to try to fix the damage.

But I've found nothing. Everything seems to work. Email flows. qmail-scanner passes to SA and Cland which do their thing. No errors in the logs. I've done two systems so far. Both EL6 (centos) x86_64.

Obviously I'm pleased. But WHY have I been spared the dance, I wonder?

Like breun said: "If a micro update doesn't do anything mail related it also won't break anything mail related."

If the MU contains fixes for qmail, it will most likely break agian...

If faris upgraded to MU#30 then MU#28 was also installed, so that's not really an explanation. It might be that it doesn't always break qmail-scanner, but only under specific circumstances. Or maybe something in a later micro update un-broke the breakage somehow? I'm still not sure what exactly causes qmail-scanner to break sometimes.

Yeah. I was at MU #27.

On updating I saw it install MU #28, #29 and #30.

On one of the systems I'm going to try restarting qmail/xinetd, and it that still works I'll restart the whole server to see if it just needs provocation.

EDIT: I backed up /var/qmail/bin before I began, and can see no difference between that backup and what's now in there. Nothing appears to have been touched, at least in terms of a quick glance and timestamps.

EDIT EDIT: Opps. I missed this change (identical filesize though)
NEW


OLD

Plesk 10.4.4 MU#41 replaces /var/qmail/bin/qmail-queue. Running yum reinstall qmail-scanner seems to fix this.

I've just picked a nasty scab having forgotten about this qmail-scanner issue completely. Stupid, stupid idiot that I am.

I have three servers all now running 11.0.9 with all the latest MU applied.

On the first server I noticed that qmail-scanner wasn't running as I'd received a few odd phishing mails which would normally have been picked up. So ran qmail-scanner-reconfigure and all was fine. The other two servers however needed the package reinstalling which was the downfall.

Same as before thousands of qmail-scanner processes get launched and each machines grinds to a halt. Very, very frustrating. The only way out seemed to be using the commands



This guarantees that the system will at least work by returning the system to normal by putting back the Plesk binaries.

Does any one know what the exact cause of this is? And is it possible to run qmail-scanner on a Plesk machine any more without risking rapid death?

Anyone have any thoughts?