Symptoms
-
Plesk is not accessible with the following 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"
-
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/lmlib
file 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/lmlib
file on the server at all; -
One of the following errors might appear in
/var/log/plesk/panel.log
file: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
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.
Resolution for infrastructure owners/providers
Make sure that the following OpenVZ kernel or newer is installed, if OpenVZ is used:
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:
In case SSH connection to the server is possible
-
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
In case SSH connection to the server is not possible
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…