Plesk Random Crashes every few days 1-3 days

[rubine2323]

I ve the same issue like some people that plesk is crashing every now and then. The logs only show that:

Jul 4 13:10:53 tender-borg setroubleshoot[196481]: SELinux is preventing /usr/sbin/sshd from open access on the file /etc/psa/.psa.shadow. For complete SELinux messages run: sealert -l 1d33a143-c6d1-41df-a8e7-075258f5f2ab
Jul 4 13:10:53 tender-borg setroubleshoot[196481]: SELinux is preventing /usr/sbin/sshd from open access on the file /etc/psa/.psa.shadow.

***** Plugin restorecon (99.5 confidence) suggests ************************
If you want to fix the label.
/etc/psa/.psa.shadow default label should be etc_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory, in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v /etc/psa/.psa.shadow

***** Plugin catchall (1.49 confidence) suggests **************************
If you believe that sshd should be allowed open access on the .psa.shadow file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sshd' --raw | audit2allow -M my-sshd
# semodule -X 300 -i my-sshd.pp

Jul 4 13:11:01 tender-borg systemd[1]: Started Session 722 of User psaadm.
Jul 4 13:11:01 tender-borg systemd[1]: session-722.scope: Deactivated successfully.
Jul 4 13:11:02 tender-borg systemd[1]: dbus-:[email protected]: Deactivated successfully.
Jul 4 13:11:03 tender-borg systemd[1]: setroubleshootd.service: Deactivated successfully.
Jul 4 13:12:18 tender-borg systemd[1]: Starting SETroubleshoot daemon for processing new SELinux denial logs...
Jul 4 13:12:18 tender-borg systemd[1]: Started SETroubleshoot daemon for processing new SELinux denial logs.
Jul 4 13:12:18 tender-borg setroubleshoot[196532]: failed to retrieve rpm info for path '/etc/psa/.psa.shadow':
Jul 4 13:12:18 tender-borg systemd[1]: Started dbus-:[email protected].
Jul 4 13:12:19 tender-borg setroubleshoot[196532]: SELinux is preventing /usr/sbin/sshd from open access on the file /etc/psa/.psa.shadow. For complete SELinux messages run: sealert -l 1d33a143-c6d1-41df-a8e7-075258f5f2ab
Jul 4 13:12:19 tender-borg setroubleshoot[196532]: SELinux is preventing /usr/sbin/sshd from open access on the file /etc/psa/.psa.shadow.

***** Plugin restorecon (99.5 confidence) suggests ************************
If you want to fix the label.
/etc/psa/.psa.shadow default label should be etc_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory, in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v /etc/psa/.psa.shadow

***** Plugin catchall (1.49 confidence) suggests **************************
If you believe that sshd should be allowed open access on the .psa.shadow file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sshd' --raw | audit2allow -M my-sshd
# semodule -X 300 -i my-sshd.pp

Jul 4 13:12:19 tender-borg setroubleshoot[196532]: SELinux is preventing /usr/sbin/sshd from open access on the file /etc/psa/.psa.shadow. For complete SELinux messages run: sealert -l 1d33a143-c6d1-41df-a8e7-075258f5f2ab
Jul 4 13:12:19 tender-borg setroubleshoot[196532]: SELinux is preventing /usr/sbin/sshd from open access on the file /etc/psa/.psa.shadow.

***** Plugin restorecon (99.5 confidence) suggests ************************
If you want to fix the label.
/etc/psa/.psa.shadow default label should be etc_t.
Then you can run restorecon. The access attempt may have been stopped due to insufficient permissions to access a parent directory, in which case try to change the following command accordingly.
Do
# /sbin/restorecon -v /etc/psa/.psa.shadow

***** Plugin catchall (1.49 confidence) suggests **************************
If you believe that sshd should be allowed open access on the .psa.shadow file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sshd' --raw | audit2allow -M my-sshd
# semodule -X 300 -i my-sshd.pp

Jul 4 13:12:29 tender-borg systemd[1]: dbus-:[email protected]: Deactivated successfully.
Jul 4 13:12:29 tender-borg systemd[1]: setroubleshootd.service: Deactivated successfully.
Jul 4 13:12:57 tender-borg NetworkManager[736]: <info> [1688476377.6671] dhcp4 (eth0): state changed new lease, address=212.227.224.43

I entered this issue in chatgpt because ive no clue how to fix it and chatgpt recommends me that:

The log suggests a few possible solutions to resolve the SELinux denial:

1. Fix the label of the /etc/psa/.psa.shadow file by running the restorecon command:
   bashCopy code
   /sbin/restorecon -v /etc/psa/.psa.shadow
2. If the previous step doesn't resolve the issue, you can generate a local policy module to allow the necessary access:
   perlCopy code
   ausearch -c 'sshd' --raw | audit2allow -M my-sshd
   semodule -X 300 -i my-sshd.pp
3. If you believe that the sshd process should be allowed open access to the .psa.shadow file by default, you can report this as a bug.

You can try the first solution by running the restorecon command and see if it resolves the issue. If not, you may need to proceed with generating a local policy module or consider reporting the problem as a bug.

Any support knows if thats the cause of the random crashes?

 

[Peter Debik]

Hi @rubine2323, could you please detail your understanding of "Plesk Random Crashes"? What exactly is happening?

 

[rubine2323]

Hi @rubine2323, could you please detail your understanding of "Plesk Random Crashes"? What exactly is happening?

Every few days it just freezes and ive to restart the server. And the Error Logs above are the only relevant thing i found.

 

[AYamshanov]

Do you really have Plesk 10.x? What OS is used?
Could it be some kind of 100% resource usage that cause system freeze? Any monitoring system is configured, do you have any graphs?
Is it real [hardware] server or virtualized server? Could it be some kind of hardware issue? Do you have an ability to see on console screen to see for last messages for the system?

 

[rubine2323]

My Version is

Plesk Obsidian
Version 18.0.53 Update #2, last updated on June 21, 2023 03:47 AM

OS
AlmaLinux 9.2 (Turquoise Kodkod)

Hardware is running at 40% RAM and 2% CPU always.

Its a VPS.
Its really hard to find any relevant logs.

Which logs could i post here which are relevant?

 

[Maarten]

This could be the issue:

Jul 4 13:12:57 tender-borg NetworkManager[736]: <info> [1688476377.6671] dhcp4 (eth0): state changed new lease, address=212.227.224.43

You should contact IONOS and ask if your VPS has a fixed IP address or a dynamic IP address. Dynamic IP addresses can cause this behavior. I've seen more issues like this on the forum.

 

[rubine2323]

I just found out that my logs are flooded with this 2 error messages:

[root@tender-borg ~]# sealert -l 1d33a143-c6d1-41df-a8e7-075258f5f2ab
SELinux is preventing /usr/sbin/sshd from open access on the file /etc/psa/.psa. shadow.

***** Plugin restorecon (99.5 confidence) suggests ************************

If you want to fix the label.
/etc/psa/.psa.shadow default label should be etc_t.
Then you can run restorecon. The access attempt may have been stopped due to ins ufficient permissions to access a parent directory in which case try to change t he following command accordingly.
Do
# /sbin/restorecon -v /etc/psa/.psa.shadow

***** Plugin catchall (1.49 confidence) suggests **************************

If you believe that sshd should be allowed open access on the .psa.shadow file b y default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sshd' --raw | audit2allow -M my-sshd
# semodule -X 300 -i my-sshd.pp


Additional Information:
Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context system_ubject_r:tmp_t:s0
Target Objects /etc/psa/.psa.shadow [ file ]
Source sshd
Source Path /usr/sbin/sshd
Port <Unknown>
Host tender-borg.212-227-224-43.plesk.page
Source RPM Packages openssh-server-8.7p1-29.el9_2.x86_64
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-38.1.11-2.el9_2.3.noarch
Local Policy RPM selinux-policy-targeted-38.1.11-2.el9_2.3.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name tender-borg.212-227-224-43.plesk.page
Platform Linux tender-borg.212-227-224-43.plesk.page
5.14.0-284.11.1.el9_2.x86_64 #1 SMP
PREEMPT_DYNAMIC Tue May 9 05:49:00 EDT 2023 x86_64
x86_64
Alert Count 163955
First Seen 2023-06-16 16:22:49 UTC
Last Seen 2023-07-08 22:56:06 UTC
Local ID 1d33a143-c6d1-41df-a8e7-075258f5f2ab

Raw Audit Messages
type=AVC msg=audit(1688856966.572:4054): avc: denied { open } for pid=5846 co mm="sshd" path="/etc/psa/.psa.shadow" dev="vda4" ino=67108999 scontext=system_u: system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_ubject_r:tmp_t:s0 tclass=file p ermissive=0


type=SYSCALL msg=audit(1688856966.572:4054): arch=x86_64 syscall=openat success= no exit=EACCES a0=ffffff9c a1=7f3ead6fb1dc a2=0 a3=0 items=0 ppid=1269 pid=5846 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(non e) ses=4294967295 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0- s0:c0.c1023 key=(null)

Hash: sshd,sshd_t,tmp_t,file,open

and:

[root@tender-borg ~]# sealert -l b84182e4-16ef-4c01-bb03-8ee008a98b78
SELinux is preventing /usr/sbin/sshd from write access on the sock_file mysql.sock.

***** Plugin catchall (100. confidence) suggests **************************

If you believe that sshd should be allowed write access on the mysql.sock sock_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sshd' --raw | audit2allow -M my-sshd
# semodule -X 300 -i my-sshd.pp


Additional Information:
Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context system_ubject_r:mysqld_var_run_t:s0
Target Objects mysql.sock [ sock_file ]
Source sshd
Source Path /usr/sbin/sshd
Port <Unknown>
Host tender-borg.212-227-224-43.plesk.page
Source RPM Packages openssh-server-8.7p1-29.el9_2.x86_64
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-38.1.11-2.el9_2.3.noarch
Local Policy RPM selinux-policy-targeted-38.1.11-2.el9_2.3.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name tender-borg.212-227-224-43.plesk.page
Platform Linux tender-borg.212-227-224-43.plesk.page
5.14.0-284.11.1.el9_2.x86_64 #1 SMP
PREEMPT_DYNAMIC Tue May 9 05:49:00 EDT 2023 x86_64
x86_64
Alert Count 40
First Seen 2023-06-16 16:17:33 UTC
Last Seen 2023-07-08 22:59:55 UTC
Local ID b84182e4-16ef-4c01-bb03-8ee008a98b78

Raw Audit Messages
type=AVC msg=audit(1688857195.469:4090): avc: denied { write } for pid=5923 comm="sshd" name="mysql.sock" dev="vda4" ino=67110104 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_ubject_r:mysqld_var_run_t:s0 tclass=sock_file permissive=0


type=SYSCALL msg=audit(1688857195.469:4090): arch=x86_64 syscall=connect success=no exit=EACCES a0=8 a1=7fff33a2ee70 a2=6e a3=80 items=0 ppid=1269 pid=5923 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null)

Hash: sshd,sshd_t,mysqld_var_run_t,sock_file,write

 

[Peter Debik]

How is the SELinux/MySQL conflict related to the initial topic?

 

[rubine2323]

Its creating 50 mb log files with this messages per 2 days. Couldnt that be the reason for the server crashes ?

 

[Peter Debik]

The idea is right, but likely not the cause, because 50 MB is "nothing". I've seen servers generating several hundred GBs within a few hours, and when these use up all available disk space it could cause halting services. But not such a low size.

 

[Kaspar]

I am inclined to say that it's much more likely that the Dynamic IP issue which @Maarten. pointed out is the source of your problems. Like @Maarten. suggested I'd suggest contacting your provider (IONOS) and inquire about your IP address. Whether or not your IP address is fixed or dynamic.

 

[rubine2323]

It cant be an IP related issue. Ive in Total 3 Plesk installations. 2 of them never crash 1 crash currently every 1-2 days. The only diffrence is between the 3 installations ive:

1x AlmaLinux 9.2 (Turquoise Kodkod)
2x CentOS Linux 7.9.2009 (Core)

The AlmaLinux installation giving me problems.
It crashed right now again and i cant find anything relevant to the crash in the error logs.
I only saw a big CPU and RAM spike right before the crash.




Its running always at arround 4% CPU and 48% RAM only right before a crash in goes to 100% and then crashes.

 

[Dave W]

Can you check traffic levels on your domains at that time?
What size VPS is this?
What you are seeing is not a crash, but a high load event, you can see that from the memory usage. It looks like one or more of your sites may be being abused.

 

[mow]

Its a VPS.
Which logs could i post here which are relevant?

You should contact IONOS and ask if there's anything in the logs of the host your VPS runs on.

 

[rubine2323]

Hello sorry for the delay. I got a new Server with 2cores 4GB Ram and 160GB SSD its currently running at about 20% Ram and 5% CPU. Traffic is not high currenlty about 60users/hour these are not my busy websites. After the upgrade the server stopped from crashing randomly.
It was a fresh install and i migrated the websites from the old server to the new one.
But again my logs are flooded with SELLinux errors like before mentiont.

SELinux is preventing /usr/sbin/sshd from open access on the file /etc/psa/.psa.shadow. For complete SELinux messages run: sealert -l 7ee8f521-d942-4473-8293-70326e3d355d

[root]# sealert -l 7ee8f521-d942-4473-8293-70326e3d355d
SELinux is preventing /usr/sbin/sshd from open access on the file /etc/psa/.psa. shadow.

***** Plugin restorecon (99.5 confidence) suggests ************************

If you want to fix the label.
/etc/psa/.psa.shadow default label should be etc_t.
Then you can run restorecon. The access attempt may have been stopped due to ins ufficient permissions to access a parent directory in which case try to change t he following command accordingly.
Do
# /sbin/restorecon -v /etc/psa/.psa.shadow

***** Plugin catchall (1.49 confidence) suggests **************************

If you believe that sshd should be allowed open access on the .psa.shadow file b y default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'sshd' --raw | audit2allow -M my-sshd
# semodule -X 300 -i my-sshd.pp


Additional Information:
Source Context system_u:system_r:sshd_t:s0-s0:c0.c1023
Target Context system_ubject_r:tmp_t:s0
Target Objects /etc/psa/.psa.shadow [ file ]
Source sshd
Source Path /usr/sbin/sshd
Port <Unknown>
Host xxxx
Source RPM Packages openssh-server-8.7p1-29.el9_2.x86_64
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-38.1.11-2.el9_2.3.noarch
Local Policy RPM selinux-policy-targeted-38.1.11-2.el9_2.3.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name xxx
Platform Linux xxx
5.14.0-284.11.1.el9_2.x86_64 #1 SMP
PREEMPT_DYNAMIC Tue May 9 05:49:00 EDT 2023 x86_64
x86_64
Alert Count 15230
First Seen 2023-07-11 07:09:59 UTC
Last Seen 2023-07-15 21:47:51 UTC
Local ID 7ee8f521-d942-4473-8293-70326e3d355d

Raw Audit Messages
type=AVC msg=audit(1689457671.727:117247): avc: denied { open } for pid=14870 2 comm="sshd" path="/etc/psa/.psa.shadow" dev="vda4" ino=402658048 scontext=syst em_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_ubject_r:tmp_t:s0 tclass=f ile permissive=0


type=SYSCALL msg=audit(1689457671.727:117247): arch=x86_64 syscall=openat succes s=no exit=EACCES a0=ffffff9c a1=7fd3599ef1dc a2=0 a3=0 items=0 ppid=1112 pid=148 702 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty= (none) ses=4294967295 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t :s0-s0:c0.c1023 key=(null)

Hash: sshd,sshd_t,tmp_t,file,open

I solved this problem on my old server by runing this commands:
/sbin/restorecon -v /etc/psa/.psa.shadow

ausearch -c 'sshd' --raw | audit2allow -M my-sshd
semodule -X 300 -i my-sshd.pp

Is that the correct way to fix that?

 

[rubine2323]

bump

 

[ivanes82]

I can confirm that plesk and almalinux 9.3 also throw constant selinux warning messages. Something is not working as it should. tested on a completely clean install.

 

[Peter Debik]

@ivanes82 How is your comment related to the issue described in this thread?

 

[n0fear]

Every few days it just freezes and ive to restart the server. And the Error Logs above are the only relevant thing i found.

Hi, is it a Amd IONOS Server? AR 12-128 maybe? Could you resolve it? Got the same problem, but not plesk is freeezing, The whole server is, no connection via ssh and so on. I tzestet allready 5 of those servers, all have the same problem...

 

[Dave W]

Sounds more like an IONOS problem than a PLESK problem tbh.