Applicable to:
- Plesk Onyx for Linux
Symptoms
-
Plesk is not accessible with the following error:
CONFIG_TEXT: [LockManagerException] Can't open or create shared memory by shm.name: "/run/lock/lmlib/SharedLockManagerStorage0.2.3"; shm.start_size: "8388608"; error "Permission denied"
-
The virtual server is purchased from an infrastructure provider (e.g. Strato) who uses OpenVZ operating system as a virtualization solution.
-
The permissions of
/run/lock/lmlibfile differ from the following and, if changed, revert back after the reboot:# stat /run/lock/lmlib
...
Access: (0770/drwxrwx---) Uid: ( 0/ root) Gid: ( 0/ lock-manager)OR
There is no
/run/lock/lmlibfile on the server at all; -
One of the following errors might appear in
/var/log/plesk/panel.logfile:CONFIG_TEXT: ERR [1] Lock Manager error: '[LockManagerException] Can't open or create shared memory by shm.name: "/run/lock/lmlib/SharedLockManagerStorage0.2.3"; shm.start_size: "8388608"; error "Permission denied"'.
OR
CONFIG_TEXT: ERR [1] Lock Manager error: '[LockManagerException] Can't open or create shared memory by shm.name: "/run/lock/lmlib/SharedLockManagerStorage0.2.4"; shm.start_size: "8388608"; error "No such file or directory"'.
Cause
Incorrect permissions are set on directories required for Plesk operation on boot.
There are two 3rd-party bugs which may cause such behavior:
-
Bug in systemd package 229-4ubuntu21.9.
Patched kernel for VZ was released for this bug but this issue may reoccur on OpenVZ6.
Resolution
Contact your infrastructure provider to make sure that the solution for the first cause is applied.
Make sure that the following OpenVZ kernel or newer is installed, if OpenVZ is used:
CONFIG_TEXT: 042stab134.7 kernel:
diff-ms-name_to_handle_at-for-empty-pathname
diff-ms-fstatat-with-empty-relative-pathnames
In order to fix the issue, OpenVZ Node kernel must be updated.
Workaround
Note: The below steps may be done by Plesk professional Services team on a paid basis as an administration service.
In order to work around the issue on Plesk instance side, create a scheduled task that will restore directory structure on reboot:
-
Log into the server via SSH as a root user.
-
Create a new Cron task to run after reboot:
# echo '@reboot root mkdir -p /run/lock/lmlib && chown root:lock-manager /run/lock/lmlib && chmod -R 0770 /run/lock/lmlib' > /etc/cron.d/00-restore-lmlib
-
Reboot the server:
# reboot
For that situation, it is required to connect to the server in the recovery mode. In the example below, recovery mode of Strato server is described:
-
Connect to the server in recovery mode
Note: Strato recovery mode can be enabled as follows: How to use RecoveryManager to access the data on your hard drive (Linux server)
-
Enter the actual container's file system:
# chroot /repair
Note: As an example, location
/repair, typical for Strato is used in this step. The location may differ. To find out the proper location contact the hosting provider. -
Create a new reboot-target Cron task:
# echo '@reboot root mkdir -p /run/lock/lmlib; chown root:lock-manager /run/lock/lmlib; chmod -R 0770 /run/lock/lmlib; mkdir -p /var/run/sshd; chmod 0755 /var/run/sshd; /etc/init.d/ssh restart' > /etc/cron.d/00-restore-runfiles
-
Exit the mounted container's environment:
# exit
-
Reboot the server:
# reboot
-
In case after the reboot Plesk is accessible, but SSH is not working, log into Plesk and navigate to Tools & Settings > Scheduled Tasks.
-
Then add the following command to the 'Command' field:
CONFIG_TEXT: mkdir /var/run/sshd && chmod 0755 /var/run/sshd && /etc/init.d/ssh restart
-
Press 'Run Now' button:
Comments
44 comments
@Tristan Huitenga
"Seriously, buying Plesk support for this? The answer is already given. Thank you Anton Maslov."
Well, his answer didn't work for me - for whichever reason! If it works: fine! If not: I guess you will need support. In my case Alisa Kasyanova's reply didn't work either ...
I saw the solution the support person implemented. NEVER would I have been able to do it myself!
We have 6 servers with the same version of Plesk. This problem is only happening on one of them. I say "its happening" but every 3-4 days I have to repeat the process described in this article. Why is this?
Hi @Kokoen,
The issue is coming from kernel/virtualization bug, so in case the issue keeps popping up, use crontasks approach as recommended in 'No SSH' part of the article.
@Tristan Huitenga
Thank you for most detailed answer i found.
It's working now!!
Thank you @Anton Maslov. Your solution Worked like a Charm!!
@Tristan Huitenga
Thank you for your detailed answer. Unfortunately, I'm trying, but nothing happens.
Can you please post the content of your /repair/var/spool/cron/crontabs/root file?
I think I messed up mine and that's the reason it doesn't work
Thanks!
Finally. Found the mistake. Now it's working!
@Patrick Sedney
Glad to know that you have figured it out!
Hello everyone,
Well i have the problem also for the secondtime but this time nothing seems to work.
Strato is not helping and im out of options.
Is there anyone who can help because damn.
I use plesk 4 years now but this is becomming a pain in the ass that im thinking about other options.
Hello @Richard,
> I use plesk 4 years now but this is becomming a pain in the ass that im thinking about other options.
The issue is not connected with Plesk itself, it is an issue of a virtual environment, where Plesk is installed.
> Well i have the problem also for the secondtime but this time nothing seems to work.
Could you let me know more details, what is the issue now and which steps have you taken to resolve the issue?
> Is there anyone who can help because damn.
You may create a ticket directly to us using a support subscription and the issue will be checked by Plesk Support.
I dont know why, but a workarround is to fix this in this form:
cd /run/lock
chown root:lock-manager lmlib
thats was - until the next restart of the virtual machine!
So as I see this on other servers with plesk in a running situation, that the group is lock-manager for this directory!
When the virtual machine was rebootet, then the user is root!
So I cant see, where the folder lmlib creates and I thing so, thats not a bug of the OS, but of plesk so as many thousends others too!
This cost us every month a new service time of many hours!
@Detlef Bracker,
Let me explain what causes the issue in details:
/run/lock/lmlib directory is created using system-tmpfiles.d, the component of systemd init system, that creates directories in `/tmp`, `/var/tmp` and `/run` locations. These locations and the content stored in them do not persist on reboot and have to be created anew during boot time.
You may find the configuration that sets up lmlib directory in `/usr/lib/tmpfiles.d/plesk-lmlib.conf` file.
In order to configure ownership on directory, systemd-tmpfiles.d uses "fstatat" system call with the "AT_EMPTY_PATH" flag before doing chmod and chown.
The flag "AT_EMPTY_PATH" was added to Linux kernel in version 2.6.39, and was later backported to OpenVZ kernel (2.6.32) in "042stab111.1": https://bugs.openvz.org/browse/OVZ-6384
In case this flag is not available, attempts to set proper ownership on the directory using systemd-tmpfiles.d fail, which leaves the lmlib directory with "root:root" ownership instead of "root:lock-manager".
As initially Linux 2.6.32 kernel, used by OpenVZ, is not supported by systemd, the developers are not planning to work around this issue: https://github.com/systemd/systemd/issues/689#issuecomment-124165376
The only way to properly fix the issue is to upgrade the kernel on the OpenVZ hardware node to at least "042stab111.1" which includes the fix from OpenVZ developers and reboot it.
Dear @Artyom Baranov
this has nothing to doe only with OpenVZ Kernel 2.6.32 why we use an absolute modern Kernel 4.15.18-12-pve !!!!
So why Plesk not create first the folder and change then the Group-User?
Or why use Plesk equal this Group-User?
It cant been, that so many Users have the same problem and Plesk switch this in the direction of a kernel problem, but the problems this exists possible in many kernels?
And we had never before, this problem comes with an automatic update from the plesk-system! We have no reboot the Host-Systems for 2 or 3 weeks, but as we have
updated 2 or 3 weeks before, we have more times booted the plesk servers!
I thing so, that Plesk again has not tested correctly, so as with many other thouthends bug, that we and other administrators have found in Plesk!
Hello @Detlef,
Thank you for the feedback.
> So why Plesk not create first the folder and change then the Group-User? Or why use Plesk equal this Group-User?
Plesk uses standard OS methods for these operations. As my colleague, Artyom has mentioned /run/lock/lmlib directory is created using system-tmpfiles.d, the component of the systemd init system.
However, Plesk development team is aware of such occurrences and a possibility to increase Plesk tolerance to such OS issues is under investigation.
> It cant been, that so many Users have the same problem and Plesk switch this in the direction of a kernel problem, but the problems this exists possible in many kernels?
Judging by the provided information, you are using Proxmox so you shouldn't be affected by OpenVZ issues. The issue was dug deeper, for your case I can suggest checking the ownership on ‘/’ directory, this may cause the same symptoms: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1811580
If this would not help, consider submitting a ticket to Plesk Technical Support.
The article was reworked.
Please sign in to leave a comment.