Failure with deleting - failure with requestmanager

**hempelr** · Nov 27th 2015

Unfortunately, the problem with the Request Manager is not yet solved.
The erase operations fail, it always remains the state "will be deleted".
What could be the problem?
Its a bit annoying, do the changes manually in the DB and the file system.

Versions:
Linux webse001 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt11-1+deb8u6 (2015-11-09) i686 GNU/Linux
mysql Ver 15.1 Distrib 10.0.22-MariaDB, for debian-linux-gnu (i686) using readline 5.2

i-MSCP Git 1.2.x / PHP 5.6.14-0+deb8u1

Why and where does imscp mount every domain-log-dir in a lvm of the server?
I can't find any mount-command - and then ist also not in ext3, all devices will be mounted as ext4 on the server.
Whats going on there with imscp - look the 3rd picture...

**Nuxwin** · Nov 27th 2015

Hello ;

Each Apache log directory is mounted (bind) into the customer log dir by the i-MSCP httpd server implementation. This allow the customer to access his Apache logs (access and error logs) in real time.

For your problem: This is due to a bug which has been solved in the 1.3.x branch. however, because the 1.3.x branch is not ready for use, it is recommended to backport the fix on your current version. See:

**hempelr** · Nov 28th 2015

Thanks nuxwin - the first point were also my thoughts, but I was not shure...

How can I backport the pm - I'll search first to solve it alone, if I do not succeed, I'll come back

Greetings
hempel

mhm - I don't think that it has to do with subdomain.pm - because the deletion of an alias-domain does not work.
Now I've deactivatet adminer, the first failure message disappears, if I try to start imscp-rqst-mngr manually.
But the second message with apache_pohp_fpm.pm is still relevant and the alias won't be deleted.

Now I've manually deleted the entry in the database (imscp - table domain_aliasses entry of the spezific alias) - and now the requestmanager starts manually witout any complaint. But the folder(s) of that alias were not deletet.
Because I've to delete some other users / domains / aliases on that server it would be nice, if I could do that with imscp - how can the issue be fixed?

somtime later:
Now I've unmounted the log-dir of a domainalias which should be deleted, and did delete in imscp. But noting in the database nor the directory-structure of the domain will occur - the status is "wird gelöscht..."
When I manual start the request-manager the samt failure message appears:
[FATAL] iMSCP::Debug::__ANON__: Could not run mount command: Unknown error at /var/www/imscp/engine/PerlLib/Servers/httpd/apache_php_fpm.pm line 1410.
Now I give it up an hope, that someone knows a solution....

it will not let me in peace
Now I did look into the perl-module, which gives the failure. The line 1410 is in sub umountLogsFolder, in the part to mount folder(s)... there must be someone a problem to mount the given folders
No, I can't understand whats going on, sorry - I need further help

sometime later:
I tried to delete a customer / whole domain - the same as above, nothing runs.

Now I need urgent help...

**hempelr** · Dec 2nd 2015

Nobody any Idea? - It would be nice, if I could delete Aliases, Subs, and Domains and also complete Accounts...

The changings, which nuxwin did say, have I done btw where always done in that perl-module.

**Nuxwin** · Dec 2nd 2015

@hempelr

Give me an SSH access to your server and I'll fix the problem.

**hempelr** · Dec 3rd 2015

ok - you have mail...

pls tell me what was the reason, because I have to update tree other servers, which have customers accounts on it, and I don`t want to run once more into this failure (all in 1.2.x. branch)

Greetings

hempelr

**Nuxwin** · Dec 3rd 2015

@hempelr

Sure, give some minutes to fix your server. Once done, I'll say you Please don't do anything on the server as long as I'm working on it

**Nuxwin** · Dec 3rd 2015

@hempelr

I've fixed the problem which was due to a wrong conditional statement for the mount/grep command result but by looking better, it appear that the engine files you're using doesn't matches those which were distributed with the version 1.2.9.

For instance, your /var/www/imscp/engine/PerlLib/Server/httpd/apache_php_fpm.pm file on line 1388

Perl

=item umountLogsFolder(\%data)
Umount logs folder which belong to the given domain from customer's logs folder
Note: In case of a partial path, any file systems below this path will be umounted.
Param hash \%data Domain data
Return int 0 on success, other or die on failure
=cut
sub umountLogsFolder
{
my ($self, $data) = @_;
my $folder = "$data->{'HOME_DIR'}/logs/$data->{'DOMAIN_NAME'}";
$self->{'eventManager'}->trigger('onUmountLogsFolder', $data);
my $fsFile;
do {
my ($stdout, $stderr);
execute("mount | grep ' $folder\$/\\| \$' | head -n 1 | cut -d ' ' -f 3", \$stdout, \$stderr) and die(
sprintf('Could not run mount command: %s', $stderr || 'Unknown error')
);
$fsFile = $stdout;
if($fsFile) { # We do not trap errors here (expected for dangling mounts)
execute("umount -l $fsFile", \$stdout, \$stderr);
}
} while($fsFile);
0;
}

Display More

when on github, for the released 1.2.9 version, we can see:

https://github.com/i-MSCP/imsc…d/apache_php_fpm.pm#L1388

So before stepping further, I would ask you: Do you tried to upgrade to another version (such as 1.3.x) and then, rolled back to version 1.2.9? Or simply put, do you really installed the released 1.2.9 version or a pre-version (aka github version)? As I see in your imscp.conf file, there is not builddate, generally meaning that you're using a Github version...

Could I simply update to real 1.2.9?

**Nuxwin** · Dec 3rd 2015

No answer... Well, I've updated to real 1.2.9.

New root password sent via pm.

**hempelr** · Dec 3rd 2015

ups - sorry, I'm on work and did not see your question / answer....

I've done updates against git, thats right. The branch is 1.2.x which is in the shellscript from the wiki.
Mhm - possibly did that break something...sorry, but I thought, that this would be the right way to have an actual webpanel with newest features....

Thanks for your help - more via pm.

I've made a new mistake, but with some searches and do a new install it is all o.k.
Thanks - that is a awesome support...problem solved and I've once more learned something.

Failure with deleting - failure with requestmanager

Share

Daily visitors