• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Upgrade to 10.4.4 - check-quota filter errors

@ IgorG

Where? I only see something about the Permission denied error.
Help me - I can´t find the single post you are talking about.

I´m still looking for this issue - this was the basic problem discussed in this thread.

Failed to run '/usr/sbin/postalias -q [email protected] hash:/var/spool/postfix/plesk/virtual', rc = 1

Only happens with external domains.
 
Hello Igor,

I second what nucknuck has said, we are also experiencing exactly the same problem:

Jan 25 03:50:47 plesk check-quota filter[7884]: Failed to run '/usr/sbin/postalias -q [email protected] hash:/var/spool/postfix/plesk/virtual', rc =

System is CentOS 6 running plesk 10.4.4

Thanks
 
same here:

Jan 25 18:04:03 web01 qmail-queue-handlers[21345]: SKIP during call 'check-quota' handler
Jan 25 18:14:59 web01 qmail-queue-handlers[22152]: SKIP during call 'check-quota' handler
Jan 25 18:15:53 web01 qmail-queue-handlers[22200]: SKIP during call 'check-quota' handler
Jan 25 18:17:12 web01 qmail-queue-handlers[22270]: SKIP during call 'check-quota' handler
Jan 25 18:20:57 web01 qmail-queue-handlers[22637]: SKIP during call 'check-quota' handler
Jan 25 18:24:13 web01 qmail-queue-handlers[22753]: SKIP during call 'check-quota' handler
Jan 25 18:24:44 web01 qmail-queue-handlers[22791]: SKIP during call 'check-quota' handler
Jan 25 18:25:59 web01 qmail-queue-handlers[22847]: SKIP during call 'check-quota' handler
Jan 25 18:31:29 web01 check-quota filter[26501]: Failed to run '/usr/sbin/postalias -q [email protected] hash:/var/spool/postfix/plesk/virtual', rc = 1
Jan 25 18:31:29 web01 /usr/lib/plesk-9.0/psa-pc-remote[26219]: SKIP during call 'check-quota' handler
Jan 25 18:33:52 web01 /usr/lib/plesk-9.0/psa-pc-remote[26219]: SKIP during call 'check-quota' handler
Jan 25 18:35:52 web01 /usr/lib/plesk-9.0/psa-pc-remote[26219]: SKIP during call 'check-quota' handler
Jan 25 18:36:02 web01 /usr/lib/plesk-9.0/psa-pc-remote[26219]: SKIP during call 'check-quota' handler
Jan 25 18:38:32 web01 /usr/lib/plesk-9.0/psa-pc-remote[26219]: SKIP during call 'check-quota' handler
Jan 25 18:43:54 web01 /usr/lib/plesk-9.0/psa-pc-remote[26219]: SKIP during call 'check-quota' handler
Jan 25 18:46:53 web01 check-quota filter[27565]: Failed to run '/usr/sbin/postalias -q [email protected] hash:/var/spool/postfix/plesk/virtual', rc = 1
Jan 25 18:46:53 web01 /usr/lib/plesk-9.0/psa-pc-remote[26219]: SKIP during call 'check-quota' handler
Jan 25 18:52:10 web01 /usr/lib/plesk-9.0/psa-pc-remote[26219]: SKIP during call 'check-quota' handler
Jan 25 18:52:31 web01 /usr/lib/plesk-9.0/psa-pc-remote[26219]: SKIP during call 'check-quota' handler
Jan 25 18:54:01 web01 check-quota filter[27787]: Failed to run '/usr/sbin/postalias -q [email protected]h:/var/spool/postfix/plesk/virtual', rc = 1
Jan 25 18:54:01 web01 /usr/lib/plesk-9.0/psa-pc-remote[26219]: SKIP during call 'check-quota' handler


10.4.4 Debian 6.0 1013111102.18
 
Last edited:
Developers are working on it. I will update thread with results.
 
Please don´t think I´m a kid that is crying because it lost his teddy ...

But anything new about this? Counted the lines in yesterday log files:

437 times ...

plesk check-quota filter[6241]: Failed to run '/usr/sbin/postalias -q [email protected] hash:/var/spool/postfix/plesk/virtual'
 
Same problem appears here.

check-quota filter[9769]: Failed to run '/usr/sbin/postalias -q [email protected]h:/var/spool/postfix/plesk/virtual', rc = 1

If I take a look into /var/spool/postfix/plesk/ there is no file named 'virtual', but only a 'virtual.db' - can the issue depend on this?
 
Hi, same problem here,
after update to 10.4.4 I find in my logs postalias running on nonexisting mailadresses.

External adresses as well as nonextisting users of local domains.

Mar 5 16:14:49 h1980300 check-quota filter[10641]: Failed to run '/usr/sbin/postalias -q [email protected] hash:/var/spool/postfix/plesk/virtual', rc = 1

Before this error did not exist

Ubuntu 10.04.2 LTS
 
Wake up Parallels

Igor, please get this sorted. It's now March. It was reported MONTHS ago.

It should have been fixed within days, not months.

We're getting the reported error several thousand times every day. What a waste of server resources...
 
nforde, if you're talking about "Failed to run '/usr/sbin/postalias [...]' ****, just ignore it. Or you can install syslog-ng and filter this useless junk out.
 
Thanks for your response, but I'm not going to be wasting more server resources removing errors that shouldn't be there in the first place.

Parallels needs to either fix the problem or confirm they're not going to fix it instead of just leaving it in limbo like this.

It's been way too long.
 
Now I´m getting pissed about this issue...

On one of the machines I had to install OSSEC ... and now I´m getting mail after mail from OSSEC because of this bug.

OSSEC HIDS Notification.
2012 Mar 07 17:03:20

Received From: lvps-spassbremse ->/var/log/mail.info
Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
Portion of the log(s):

Mar 7 17:03:20 lvps-spassbremse check-quota filter[28459]: Failed to run '/usr/sbin/postalias -q [email protected] hash:/var/spool/postfix/plesk/virtual', rc = 1

This happens at every single external mail. And: the OSSEC mail is send to external receiver and causes also a new entry in the log, that causes a new OSSEC mail that causes a new entry in the log and so on and so on ...

OSSEC stopped at the moment after 241 mails within one hour.

What about fixing this bug/feature/piece of dirt?!
 
I have same problem emails does not going out as expected. When this will be fixed?
 
Developers are working on it. I will update thread with results.

Igor, can you PLEASE do this soon - it's been months.

ps. Parallels *really* needs a public bug tracking system - hopefully someone over there is at least considering it.
 
86

Yes, this bug has been reported in different ways at least 86 days ago.

A fix? - NO!
A workaround? - NO!
A date for solving this issue? - NO!

I ask - why?

Waiting for an answer...
 
I have escalated this issue. I hope that we receive results soon.
 
Back
Top