Why an CLI program needs a HTTP request to the installation at all?

In your Settings > System check, do you see "Ok" next to "Managing CLI processes" item?

With a proxy is defined or not, I see:
Archive Cron (green check icon) Managing processes via CLI: not supported (optional)

Why an CLI program needs a HTTP request to the installation at all?

The CLI has a few required checks before it can be used: https://github.com/piwik/piwik/blob/master/core/CliMulti/Process.php#L142-166

had to debug it because the error message was not really good: ".....you have to increase memory limit normally" or something like that

Ok that sounds like a bug. Feel free to create ticket for it or even pull request :-)

can you try to type the ./console core:archive --url=X -v
and then paste output? the -v will enable verbose output which will give some more info

maybe a solution could be to "ignore" the proxy settings when attempting to contact

• localhost / 127.0.0.1 etc.
• a hostname found within the trusted_hosts array in config file

We'd have to document this in the proxy FAQ as maybe some users don't want it somehow and could let us know

I have the same problem and have used the idea from #6711
This is now my patch file and it works:

--- piwik_dist/core/Http.php    Mon Jan  5 05:35:22 2015
+++ piwik/core/Http.php Thu Jan 29 13:25:32 2015
@@ -161,6 +161,16 @@
         $proxyPort = Config::getInstance()->proxy['port'];
         $proxyUser = Config::getInstance()->proxy['username'];
         $proxyPassword = Config::getInstance()->proxy['password'];
+        $proxyExcludes = explode(" ", Config::getInstance()->proxy['excludes']);
+        foreach($proxyExcludes as $proxyExclude)
+        {
+            if (strpos($aUrl, $proxyExclude) !== false)
+            {
+                $proxyHost = '';
+                $proxyPort = '';
+                break;
+            }
+        }

         $aUrl = trim($aUrl);

and in the config/config.ini.php I have:

[proxy]
host = "ip.of.my.proxy"
port = 8080
excludes = "127.0.0.1 192.168.1.2"

Just got (sadly) back to this issue.

My archives were exploding from 200MB to 5GB and i was wondering why.

When executing php console core:archive --url=http://xxx/ the ScheduldedTask wanted to execute GeoIPAutoUpdater and failed, because the connection failed.

Somehow some rows were written to the archive and some not, so the archive exploded (need to verify that a bit)

The core:archive was last sucessfull 27 days ago, because of the GeoIPAutoUpdater.

Cant we make a "special" dispatch for the console core:archive which does "ignore" ScheduldedTasks and such things? So it can never fail because of "3rd" party code