Subdomain: Deletion in progress...

  • Hello,


    I tried to delete some subdomains but all I get is a Deletion in progress... message. I tried to take a look into the /var/log/imscp/imscp-rqst-mngr.log log but it is empty.



    There was also a strange behavour:
    The first deletion try the only thing that changed in the list was that the letsencrypt configuration seemed to be deleted (subdomain switched in the list to ssl disabled). At the second try it stucked.



    Details:


    System: Ubuntu 16.04.1 LTS (new installation)


    I-MSCP: 1.3.14 Build 20161227 Codename Horner
    PHP: PHP-FPM

  • Greetings, @UncleSam


    I have been experiencing a similar issue since I configured my first i-MSCP installation (on 1.3.8) just a few weeks ago. I have done a fair amount of troubleshooting and finally created my first Bug Tracker case just a couple of hours ago.


    The problem occurs for me on Ubuntu LTS Server 14.04.5 “Trusty Tahr.” I have confirmed that does not affect Debian 8.6 “Jessie.” I had not tested Ubuntu LTS 16.04.1 “Xenial Xerus”, so I am pleased to see a possible confirmation from another user on the newer Ubuntu release. This would seem to confirm it is am Ubuntu-specific bug.


    If you run a “df -a” do you see duplicate mounts at the end of the list?


    While we await a fix, I believe this should provide a workaround to remove extraneous mounts that seem to be causing the failure (if you are seeing the same thing happening for you):

    Code
    1. df -a | grep /var/www/virtual | tr -s " " | cut -d " " -f 6 | sort | xargs -n1 umount

    After this, you should be able to clear the “hung” deletion by navigating to the “System Tools/Debugger” page (as Admin) and scrolling to the bottom for the “Pending Tasks” and click “Execute Tasks.” If that doesn’t work, run my “workaround” again and then run an imscp-autoinstall -d


    Hope this helps! I am confident that Laurent will have no trouble solving this now that we are closing in on an explanation.


    Happy New Year!

    Regards,


    /\/\___


    “There are 10 kinds of people. Those who understand base-2 and those who do not.”

    Edited 2 times, last by innodapt ().

  • @innodapt


    The point is: there should be no duplicate mounts. Waiting for access data to your server ;)

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • @Nuxwin has provided a solution for us Ubuntu users:


    # cd /etc
    # mv mtab mtab-disabled
    # ln -s /proc/mounts mtab
    # service imscp_mountall restart

    It turns out this is happening because evidently /etc/mtab is not symlinked to /proc/mounts by default on Ubuntu LTS 14.04 as it is on Debian. Creating the link manually (as above) should solve the problem for all affected “Trusty Tahr” users.


    Future versions of the installer will include this fix for Trusty Tahr.


    Thanks, @Nuxwin for a real fix and @UncleSam for confirming the problem on Ubuntu 16.04.1

    Regards,


    /\/\___


    “There are 10 kinds of people. Those who understand base-2 and those who do not.”

    Edited 3 times, last by innodapt ().

  • @innodapt


    Are you sure that the @UncleSam problem is also due to duplicate bind mounts? I see nothing in his report confirming this ?(

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • I see nothing in his report confirming this

    Hmmm… Good point.


    I will check the behavior on 16.04.1 right now in a VM, but you are wise to ask that question. @UncleSam is offline right now…

    Regards,


    /\/\___


    “There are 10 kinds of people. Those who understand base-2 and those who do not.”

  • @innodapt


    Great ;) Waiting for the result ;)


    Your help is much appreciated ;)

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • I just set up a Xenial VM to “inspect what I suspected.” It turns out /etc/mtab is in fact symlinked to ../proc/self/mounts by default on Ubuntu LTS Server 16.04.1 “Xenial Xerus”


    So… unless your symlink is missing, @UncleSam, it looks like you have a different problem. :(

    Regards,


    /\/\___


    “There are 10 kinds of people. Those who understand base-2 and those who do not.”

  • @innodapt


    Thank you for testing ;)


    @UncleSam


    Please, with the domain hanging on 'Deletion in progress...', execute:

    Shell-Script
    1. # perl /var/www/imscp/engine/imscp-rqst-mngr -v

    and post us the full result.


    Also, don't forget to give us the list of plugins you're using.


    Thank you.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • About @innodapt problem


    This is due to the fact that under Ubuntu < 16.04, /etc/mtab is a regular file while it is expected to be a symlink to /proc/mounts. The iMSCP::Mount library make use of the MOUNT(2) and GETMNTENT(3) system calls. The problem is that the MOUNT(2) system call, unlike the MOUNT(8) command, doesn't update the /etc/mtab file which is read by the GETMNTENT(3). The only way to solve this is to make /etc/mtab a symlink to /proc/mounts. Furthermore, the regular /etc/mtab file seem deprecated since a while. A regular file that is part of a mounted fs and containing mounts info is a broken concept as explained in second link below.


    - https://github.com/systemd/systemd/issues/1495
    - https://sourceware.org/bugzilla/show_bug.cgi?id=19108


    @innodapt Thank for the links ;)

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206