Plesk is not accessible: Can't open or create shared memory by shm.name

Follow

Comments

44 comments

  • Avatar
    Roland Finke (Edited )

    @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! 

    1
    Comment actions Permalink
  • Avatar
    Kokoen

    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? 

    1
    Comment actions Permalink
  • Avatar
    Alexandr Redikultsev

    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.

    -1
    Comment actions Permalink
  • Avatar
    Mamija

    @Tristan Huitenga

    Thank you for most detailed answer i found.

    It's working now!!

    0
    Comment actions Permalink
  • Avatar
    Ameenullah S (Edited )

    Thank you @Anton Maslov. Your solution Worked like a Charm!!

    0
    Comment actions Permalink
  • Avatar
    Patrick Sedney

    @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!

    1
    Comment actions Permalink
  • Avatar
    Patrick Sedney

    Finally. Found the mistake. Now it's working!

    1
    Comment actions Permalink
  • Avatar
    Alisa Kasyanova

    @Patrick Sedney
    Glad to know that you have figured it out!

    0
    Comment actions Permalink
  • Avatar
    Richard Ebben

    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.

    1
    Comment actions Permalink
  • Avatar
    Ivan Postnikov

    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.

    -1
    Comment actions Permalink
  • Avatar
    Detlef Bracker

    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!

     

    0
    Comment actions Permalink
  • Avatar
    Artyom Baranov

    @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.

    -1
    Comment actions Permalink
  • Avatar
    Detlef Bracker

    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!

     

     

    0
    Comment actions Permalink
  • Avatar
    Ivan Postnikov

    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.

     

    0
    Comment actions Permalink

Please sign in to leave a comment.

Have more questions? Submit a request