Search results

Tks Igor, logged as #183672

Thanks Igor, I've enabled the settings you suggested and will report back when more information will become available. Appreciated.

Hi Igor, thanks for the follow-up. We can't unfortunately provide remote access to any of the affected machines, but we're more than willing to assist in investigating the issue, which is still occurring on a daily basis. What we need to know at the moment is: which one of the daily tasks listed...

As long as there is some way to define the default "Rank Tracker crawls" resource limit for EXISTING service plans on adding this extension I'd be happy - or you could monetise by some method *other* that key word, the I wouldn't care about the default being unlimited.

Done Igor, hopefully it's readable at your end. Thanks.

Submitted as a bug: Plesk 17.8.11, upgraded from 17.5.3: high load average caused by /etc/cron.daily/50plesk-daily It keeps happening and we find it unacceptable.

TITLE: Plesk 17.8.11, upgraded from 17.5.3: high load average caused by /etc/cron.daily/50plesk-daily PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE: Plesk Onyx Version 17.8.11 Update #56, last updated on June 19, 2019 09:42 PM CentOS Linux 7.6.1810 (Core)‬ PROBLEM DESCRIPTION: We haven't seen...

TITLE: SEO Toolkit sets Rank Tracker crawls to unlimited on all existing service plans PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE: SEO Toolkit 1.1.6-47 + (Personal plan) Plesk Onyx Version 17.8.11 Update #56 CentOS Linux 7.6 PROBLEM DESCRIPTION: When SEO Toolkit extension is added to plesk...

Update: logging out of the panel by forcing /logout.php3 and logging back in fixed the pop-up issue.

TITLE: [CentOS 7] After 17.5.3 -> 17.8.11 in-place upgrade the panel becomes unusable PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE: Plesk Onyx 17.8.11 Update #57, CentOS 7.6.1810 (Core) PROBLEM DESCRIPTION: Right after upgrading , once I logged in and accepted the T & Cs, a new pop up keeps...

This just keeps going, every night the load average on our servers explodes, sometimes to 650+, which is unacceptable. Check this out: grep '/usr/local/psa/admin/bin/event_handler -i -u psaadm /usr/local/psa/admin/bin/php -- -f /usr/local/psa/admin/plib/scripts/interface_async_executor.php --...

On a closer inspection of our logs it turns out Plesk runs these event handlers for every subscription: server1: actionlog__event_siteapp_upgrade - 64 actionlog__event_domain_guid_update - 869 actionlog__event_domain_status_update - 869 server2: actionlog__event_siteapp_upgrade - 68...

CentOS 7.6, Plesk Onyx Version 17.8.11 Update #54 upgraded from 17.5.3. We haven't seen this behaviour in 17.5.3 with the current set of tasks which reads: /usr/local/psa/bin/sw-engine-pleskrun /usr/local/psa/admin/plib/DailyMaintainance/script.php -f...

Excellent, thanks

Yep, thanks. How can I get the psa-proftpd src.rpm package as built by Plesk? I'd like to recompile it using test several 1.3.6 master branch iterations. It's important for us to run a fast 1.3.6 build without compromising the security by downgrading to 1.3.5.

Sorry to dig up a nearly 12 months old thread, but I think there's an issue in ProFTPD 1.3.6 shipped with 17.8.11: Bug 4360 – slow directory listing in 1.3.6 in comparison to 1.3.5d We've just seen it on a CentOS 7.6 server running 17.8.11. Comparing the results on a directory containing 164289...

Good idea, instead of writing to tmpfile I'm using syslog and here's what I got: May 31 14:47:25 host01 dovecot: report-spam.sh: id=uid=110(popuser) gid=31(popuser) groups=31(popuser),97(dovecot) env=HOST=plesk USER=spamcop_spam@domain.com PWD=/mnt/xvda3/qmail/mailnames/domain.com/spamcop_spam...

It works from cli Igor, as root: echo "test" | /usr/sbin/sendmail -f "noreply@123.com" "test@domain.com" [root@plesk ~]# May 30 15:30:47 plesk postfix/pickup[1838]: 83D47954A07: uid=0 from=<noreply@123.com> May 30 15:30:47 plesk postfix/qmgr[32372]: 83D47954A07: from=<noreply@123.com>...

Thanks Igor. There's nothing wrong with /usr/local/psa/handlers/spool, it's owned by popuser:popuser. If it wasnt, or if there were write issues due to filesystem being mounted read-only we'd have had much bigger issues, no local delivery would have worked :) stat /usr/local/psa/handlers/spool...

Thanks Igor, the mount points/options have got nothing to do with the issue. It looks like Plesk decided for 17.8 to hide the original /usr/bin/sendmail.postfix and /usr/sbin/postdrop under /usr/lib64/plesk-9.0/sendmail/ owned by root:plesksendmail, 750 access mode. They've been replaced by a...