vlogger: Apache workers not closed on mis-configured vlogger

  • 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
    1. [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
    1. [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
    1. 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

  • @Starlight


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


    Thank you.

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

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

  • 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
    1. 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
    1. 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
    1. 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
    1. root@wheezy:/usr/local/src/imscp/configs/debian/apache# LANG=C perl -T vlogger
    2. 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

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

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

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