vlogger: Apache workers not closed on mis-configured vlogger

**Starlight** · Oct 5th 2016

Since upgrading vlogger to v1.9, I had a strange phenomena: The apache workers got eaten up even in idle times.

Checking the apache server log, I saw hundreds of those entries:

Code

[Wed Oct 5 20:00:25 2016] [alert] i-MSCP Vlogger: error while tracker dump: DBI connect('database=imscp;host=db.xxxxx.com;port=3306','vlogger_user',...) failed: Unknown MySQL server host 'db.xxxxx.com' (2) at /usr/local/sbin/vlogger line 494.

Interestingly, since the connect sting was not mis-configured. If mis-configured, vlogger would complain on start up and turn the feature off:

Code

[Wed Oct 5 22:12:31 2016] [alert] i-MSCP Vlogger: could not connect to MySQL server: Unknown MySQL server host 'db1.xxxxx.com' (0)[Wed Oct 5 22:12:31 2016] [alert] i-MSCP Vlogger: tracker feature turned off

Checking vloggers line 494, leads me to the sub routine dumpTracker's connect string:

Code

my $dbh = DBI->connect($DBI_DSN, $DBI_USER, $DBI_PASS, { AutoCommit => 1, PrintError => 0, RaiseError => 1 });

I replaced the hostname with the server's IP address in /etc/imscp/apache/vlogger.conf and it works. I do not know, why this connect string is not working with domain names (anymore).

Two things should be done now:
1) fix the error string
2) close open sessions to avoid workers getting eaten up

I opened a Bug request: IP-1638

**Nuxwin** · Oct 5th 2016

@Starlight

See my answer in the issue you have created. Also please, communicate us your vlogger conffile (hide sensitive data).

Thank you.

**Starlight** · Oct 5th 2016

I added my vlogger host file in the ticket. Should be no derivation from the standard. However, I changed the hostname to IP (temporary fix) to make it work again.

If vlogger is not eating up the apache workers, what could do this? I started after the upgrade.

**Nuxwin** · Oct 6th 2016

Quote from Starlight

If vlogger is not eating up the apache workers, what could do this? I started after the upgrade.

Well, after analysing the code, I see that even when the dump fails (or when the tracker feature is turned off when starting up), the hash table in which the data are stored continues to grow over the time, and of course, this can lead to out of memory problems... The consumed memory for the process would never stop to grow. That's what you meant?

For the second problem about the hostname

First, you should tell us which was your previous i-MSCP version. What I can say here is that we do a chroot() call after the first connection attempt and thus, this could explain hostname resolution problem. For instance:

Perl

use Socket;use Data::Dumper;my @addresses = gethostbyname('host.domain.tld') or die "Can't resolve: $!\n";@addresses = map { inet_ntoa($_) } @addresses[4 .. $#addresses];print Dumper(\@addresses);

Will work as expected:

Code

root@wheezy:/usr/local/src/imscp/configs/debian/apache# LANG=C perl -T vlogger$VAR1 = [ '<ip_addr>' ];

but the same thing after a call to chroot():

Perl

use Socket;use Data::Dumper;chroot('/var/log/apache2');my @addresses = gethostbyname('host.domain.tld') or die "Can't resolve: $!\n";@addresses = map { inet_ntoa($_) } @addresses[4 .. $#addresses];print Dumper(\@addresses);

will result to the following error:

Code

root@wheezy:/usr/local/src/imscp/configs/debian/apache# LANG=C perl -T vlogger
Can't resolve: No such file or directory

So here, we have two possibilities:

We don't chroot
We resolve hostname before the chroot() call and pass the resulting IP to DBI instead of the hostname

**Nuxwin** · Oct 8th 2016

A fix has been added in the 1.3.x branch. See

This fix will be part of next release.

Thank you for your report.

Thread closed.

vlogger: Apache workers not closed on mis-configured vlogger

Share

Daily visitors