Hello, @brother4 . Could you please confirm if by excluded you mean the directory has been added into the Imunify's Ignore list? Also, could you please provide an example of the notification(s) you receive for the disabled domain? Thank you in advance.
@jescayola . do you happen to have HTTP/3 support enabled for the domain name in question? If yes, could you please try disabling it for the sake of testing?
Thank you for the clarification. I misunderstood that the cron remains rather than the system user. I was able to replicate the behavior now. I will double-check with our team and follow-up with more details.
So far, our developers haven't identified any real impact resulting from the thrown error - MariaDB appears to be operating properly. Still, at this point, I cannot guarantee unexpected issues won't arise. I will follow-up with more details as soon as possible. Thank you for your patience in the...
Thank you for the update and clarification. My point is, that if you do not interact with the scheduled tasks while the subscription is in suspended state, the issue should not occur. Nevertheless, this is just a workaround suggestion until our team introduce an official fix for the issues. They...
If your end goal is to have different system users for the production and staging environments, then, yes, Web Pro Edition is probably your best option as the entry point including subscription management. The other option is to review the command and, if possible, to adjust it so it could be...
Hi, @carlsson . If you have already tried the suggestion of @Bitpalast for settings the threshold to 30% and that did not work, please try setting them to an even higher value, for example 50%.
Hello, @Matt N . This issue is currently under investigation from our team. As far as I understand it is suspected as a MariaDB upstream issue, but I will be able to provide further clarification later on.
I am glad to hear you were able to sort out it out. According to our developers the issue likely occurred because the Laravel toolkit database was locked in the moment the domain was renamed. Unfortunately, since this is conditional event and it cannot be reproduced it is difficult for our team...
Hi, @bigbear67 . Thank you for the report. It is already forwarded to our team for further review. Please refer to the following thread for further updates:
Issue - Plesk 18.0.74 too short log page (only 5 lines)
Hello, @RegioOnline . Thank you for the report. Unfortunately, I was unable to replicate the behavior. I tried cloning the website under a subdomain associated with the same domain and with a different one (under the same subscription). In both cases, the cron task remained unaltered. I would...
@TomBoB , please try executing the following commands and confirm if it returns any IDs:
plesk db
select domains.name,Subscriptions.id from domains right join Subscriptions on domains.id=Subscriptions.object_id where domains.name is null;
Thank you for the update. There could be some inconsistency in the Laravel Toolkit database. Could you please check it out by executing the following command:
sqlite3 /usr/local/psa/var/modules/laravel/laravel_toolkit.sqlite
select * from applications where id = 1;
Please make sure to replace...
Thank you for your patience. The disappearance of the description was registered as bug identified with ID PPPM-15196. The prepending of the PHP binary location with PPPM-15210. Regarding the latter, our team determined that this only occurs if the scheduled task is modified while the...
Hello, @presswizards . Imunify is a third-party extension distributed by CloudLinux, therefore, we do not reflect all changes performed on their end in our changelog. I consulted with the team and the confirmed that all installations should have new version of the ai-bolit package >= 1:32.7.4-1...
I was able to locate similar error to the last entry and in most cases the issue was due to corruption of the plesk-web-hosting package. @safemoon , could you please try:
rpm -qa | grep hosting
and let us know if any errors are returned?