Subdomain: Deletion in progress...

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):

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!

@innodapt

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

@Nuxwin has provided a solution for us Ubuntu users:

Quote from Nuxwin

# 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

@innodapt

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

Quote from Nuxwin

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…

@innodapt

Great Waiting for the result

Your help is much appreciated

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.

@innodapt

Thank you for testing

@UncleSam

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

and post us the full result.

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

Thank you.

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