• 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

Issue Issue with/etc/cron.daily/logrotate after 18.0.34 upd

Vince

New Pleskian
Hi,

I have the following issue, with 3 different VPS since v18.0.34 update has been done.
All 3 VPS are on CentOS 7.9.2009 (Core).

Recieving 1 email "Anacron job 'cron.daily'" per server every night with these informations :
/etc/cron.daily/logrotate:
ls: cannot open directory /usr/lib64/httpd/modules: Permission denied failed to open semaphore file /usr/local/psa/var/utilities.sem: Permission denied System error 13: Permission denied

Is there something to do to fix it ?
Thanks in advance
 
Permissions of the file utilities.sem should be 0600, owner is root, group is root.
What's your output of
# ll /usr/local/psa/var/utilities.sem

Permissions of the directory /usr/lib64/httpd/modules should be 0755, owner is root, group is root.
 
Here are the infos , but all seems to be ok :
ll /usr/local/psa/var/utilities.sem
-rw-------. 1 root root 0 Oct 9 11:18 /usr/local/psa/var/utilities.sem
And
ll /usr/lib64/httpd
total 8
drwxr-xr-x. 2 root root 4096 Mar 13 15:57 modules

I don't know if it could help, but i have 2 other VPS on 18.0.34 on Ubuntu 20.04, and they don't have the same issue.
I only recieve notifications for Centos 7 Servers.
 
Last edited:
Yes, no problem at all during updates, no error messages.

To be honest, all is working fine besides these notifications.
I don't even know if it's important or not...

To my understanding (i'm a bit beginner) it seems to have a link to log rotations.
So i suppose at worst case, they are not done and logs are going to grow, wich can saturate hdd at some point (?)
 
There have been some forum entries about similar situations in the past. One suggested to check SELinux. Maybe you can temporarily disable it then re-enable it and then see if it works afterwards?

Another entry suggested to delete the .sem file, then restart the psa service like
# service psa restart
but I don't feel that this sounds like a plausible solution.

It is also possible that some file or directory permissions are wrong, which could be fixed with a
# plesk repair installation

And it is also possible that the logrotate daemon is not run as root. But there is no "standard" fix for that, because then it would be interesting to first figure out under which account it is running and why.

On a virtual server it is also possible that system resource limits like inodes have been exceeded, which can cause all kinds of strange issues.
 
Thanks for your help, i'm going to try.

But first, is there a risk to do any of these actions ?
(Disabling/re eanbling SElinux, Deleting sem file + restart psa service, or launch a plesk repair)

As i said i'm pretty beginner, servers are in production and i don't want to do something wrong...
 
There should not be any risks involved unless something was installed totally wrong in the first place.
 
I have the same problem. I received error mails on three of the five units.

/etc/cron.daily/logrotate:
ls: cannot open directory /usr/lib64/httpd/modules: Permission denied
failed to open semaphore file /usr/local/psa/var/utilities.sem: Permission denied
System error 13: Permission denied

CentOS Linux 7.9.2009 Plesk Obsidian 18.0.34

a16 -- WebHostEd. --- I received an error message.
a17 -- WebHostEd. --- I received an error message.
a18 -- WebAdminEd. --- I received an error message.
a19 -- WebAdminEd. --- No error messages.
a20 -- WebAdminEd. --- No error messages.


[a16 ~]$ ll /usr/local/psa/var/utilities.sem
-rw-------. 1 root root 0 Oct 29 2019 /usr/local/psa/var/utilities.sem

[a17 ~]$ ll /usr/local/psa/var/utilities.sem
-rw-------. 1 root root 0 Nov 3 2019 /usr/local/psa/var/utilities.sem

[a18 ~]$ ll /usr/local/psa/var/utilities.sem
-rw-------. 1 root root 0 Nov 7 2019 /usr/local/psa/var/utilities.sem

[a19 ~]$ ll /usr/local/psa/var/utilities.sem
-rw-------. 1 root root 0 Nov 11 2019 /usr/local/psa/var/utilities.sem

[a20 ~]$ ll /usr/local/psa/var/utilities.sem
-rw-------. 1 root root 0 Nov 20 2019 /usr/local/psa/var/utilities.sem

[a16 ~]$ sestatus | grep "Current mode"
Current mode: enforcing

[a17 ~]$ sestatus | grep "Current mode"
Current mode: enforcing

[a18 ~]$ sestatus | grep "Current mode"
Current mode: enforcing

[a19 ~]$ sestatus | grep "Current mode"
Current mode: enforcing

[a20 ~]$ sestatus | grep "Current mode"
Current mode: enforcing

-------------------------
The following were implemented. See how it goes.

[a17 ~]# setenforce 0
[a17 ~]# sestatus | grep "Current mode"
Current mode: permissive
[a17 ~]# setenforce 1
[a17 ~]# sestatus | grep "Current mode"
Current mode: enforcing
[a17 ~]#


[a18 ~]# plesk repair installation -verbose
Reconfiguring the Plesk installation
.......
done
**** Product repair completed successfully.
[a18 ~]#
 
Last edited:
We have already submitted the report about this issue: PPPM-12853
Developers are working on it.
 
Last edited:
CentOS Linux release 7.9.2009 (Core) Plesk Obsidian18.0.34

I am not a native speaker of English.

I have the same problem.
Therefore, we are running the machine with the "SELINUX" status set to "Permissive".
I am waiting for your solution.
 
1. Disabling and re-enabling SELinux.
1. plesk repair installation

There was no change in the results. I received the same error email.
 
While the fix is preparing for release in the next Plesk update as a temporary solution, I can recommend a temporary switch SELinux off.
 
Hi!
There is a second issue (or maybe solved already issue) which came together with this one.
channel: no 'mirrors.sought.rules.yerp.org' record found, channel failed
17-Mar-2021 05:35:44: SpamAssassin: Update available, but download or extract failed

Could you please help with this too?
I started to receive both messages about logrotate and spamassassin update chanel at the same night.

I have Plesk Obsidian 18.0.34.
 
While the fix is preparing for release in the next Plesk update as a temporary solution, I can recommend a temporary switch SELinux off.
Good day!
I’m running Plesk more as a power user, and not as a hosting/subscription model, meaning I’m the only Plesk user and all websites are my own. Given that, what are the security risk in disabling SELinux?

Thank you!
 
Back
Top