Hi @mstenz when you go to Matomo => Admin => Plugins, can you check if the GeoIP2 plugin is enabled? If not, can you try to enable it and see if works now?

Hi @tsteur
Yes, the plugin is enabled. Today the settings were again reset. Don't know whats going on. I have enabled the log settings, but there is no error about this inside. This was working since years, but now after the update makes issues.

@mstenz just to correctly understand. You basically need to configure Geolocation every time from scratch and need to configure things like the URL from where to download the file and get Matomo to download it etc?

Any chance you can send us the output of your Matomo system report? You find it in "Matomo => Admin => System check" and the output should be anonymised.

Just enabled debugging and found out that:

• geo2ip works fine after first activated
  Line 520: DEBUG UserCountry[2020-12-27 21:05:50 UTC] [4348] GEO: Found IP 188.242.109.176 location (provider 'geoip2php'): array (

• after first configuration and when the geo2ip configuration page is opened a second time it get automatically disabled. error message from my first comment.
  Line 70971: DEBUG UserCountry[2020-12-28 01:59:51 UTC] [8492] GEO: no current location provider sent, falling back to default 'default' one.

# Mandatory checks

## PHP-Version >= 7.2.5: ✔ 7.4.1


## PDO Erweiterung: ✔ 


## PDO\MYSQL Erweiterung: ✔ 


## MYSQLI Erweiterung: ✔ 


## Weitere erforderliche Anforderungen: ✔ zlib ✔ SPL ✔ iconv ✔ json ✔ mbstring ✔ Reflection


## Erforderliche Funktionen: ✔ debug_backtrace ✔ eval ✔ hash ✔ gzcompress ✔ gzuncompress ✔ pack


## Benötigte PHP Konfiguration (php.ini): ✔ session.auto_start = 0 ✔ max_execution_time = 0 OR >= 30


## Verzeichnisse mit Schreibzugriff: ✔ $DOC_ROOT\tmp ✔ $DOC_ROOT\tmp\assets ✔ $DOC_ROOT\tmp\cache ✔ $DOC_ROOT\tmp\climulti ✔ $DOC_ROOT\tmp\latest ✔ $DOC_ROOT\tmp\logs ✔ $DOC_ROOT\tmp\sessions ✔ $DOC_ROOT\tmp\tcpdf ✔ $DOC_ROOT\tmp\templates_c


## Verzeichnisse mit Schreibzugriff auf Tag Manager: ✔ $DOC_ROOT\js



# Optional checks

## Dateiintegrität: ✔ 


## Tracker-Status: ✔ 


## Speicherlimit: ✔ 1024M


## Zeitzone: ✔ 


## Öffnen einer URL: ✔ curl


## PageSpeed deaktiviert: ✔ 


## GD > 2.x + Freetype (graphics): ✔ 


## Andere Erweiterungen: ✔ json ✔ libxml ✔ dom ✔ SimpleXML


## Andere Funktionen: ✔ shell_exec ✔ set_time_limit ✔ mail ✔ parse_ini_file ✔ glob ✔ gzopen ✔ md5_file


## Dateisystem: ✔ 


## Cron einrichten - Prozesse via CLI steuern: nicht unterstützt (optional)


## Letzter erfolgreicher Abschluss der Archivierung: ✔ Der Archivierungsprozess wurde vor 00:46:13 erfolgreich abgeschlossen.


## Datenbankfähigkeiten: ✔ UTF8mb4 charset ✔ LOAD DATA INFILE ✔ CREATE TEMPORARY TABLES ✔ Changing transaction isolation level


## Maximale Packetgröße: ✔ 


## Erzwungene SSL Verbindung: ✔ 


## Standorterkennung:⚠ Error: The configured geolocation provider <strong>DBIP / GeoIP 2 (Php)</strong> is broken. Please fix the provider or configure another one to get geolocation working again.


## Update über HTTPS: ✔ 


## Schreibbarer JavaScript-Tracker ("/matomo.js" & "/piwik.js"): ✔ 



# Informational results

## Matomo Version: 4.1.0


## Matomo Update History: 4.0.0,3.13.3,


## Matomo Install Version: Unknown - pre 3.8.


## PHP_OS: WINNT


## PHP_BINARY: C:\Program Files\PHP\v7.4\php-cgi.exe


## PHP SAPI: cgi-fcgi


## Timezone Version: 2019.3


## PHP Timezone: UTC


## PHP Time: 1609121590


## PHP Datetime: 2020-12-28 02:13:10


## PHP INI max_execution_time: 600


## PHP INI post_max_size: 256M


## PHP INI max_input_vars: 1000


## PHP INI zlib.output_compression: 


## Curl Version: 7.67.0, OpenSSL/1.1.1d


## Suhosin Installed: 0


## DB Prefix: 


## DB Charset: utf8mb4


## DB Adapter: PDO\MYSQL


## MySQL Version: 8.0.22


## Num Tables: 421


## Browser Segment Archiving Enabled: 1


## Development Mode Enabled: 0


## Internet Enabled: 1


## Multi Server Environment: 0


## Custom User Path: 0


## Custom Include Path: 0


## Plugins Activated: API, Actions, Annotations, BulkTracking, Contents, CoreAdminHome, CoreConsole, CoreHome, CorePluginsAdmin, CoreUpdater, CoreVisualizations, CustomDimensions, CustomJsTracker, CustomVariables, DBStats, Dashboard, DevicePlugins, DevicesDetection, Diagnostics, Ecommerce, Events, Feedback, ForceSSL 4.0.1, GeoIp2, Goals, Heartbeat, ImageGraph, Insights, Installation, Intl, IntranetMeasurable, LanguagesManager, Live, LogViewer 4.0.1, Login, Marketplace, MobileAppMeasurable, MobileMessaging, Monolog, Morpheus, MultiSites, Overlay, PagePerformance, PasswordVerifier 0.2.0, PrivacyManager, ProfessionalServices, Provider, Proxy, QueuedTracking 4.0.2, Referrers, Resolution, RssWidget, SEO, ScheduledReports, SecurityInfo 4.0.1, SegmentEditor, SitesManager, TagManager, TasksTimetable 4.0.2, Tour, Transitions, TwoFactorAuth, UserCountry, UserCountryMap, UserId, UserLanguage, UsersManager, VisitFrequency, VisitTime, VisitorInterest, VisitsSummary, WebsiteMeasurable


## Plugins Deactivated: GroupPermissions 3.9.1, Widgetize


## Plugins Invalid: 


## Server Info: Microsoft-IIS/10.0


## Had visits in last 1 day: 1


## Had visits in last 3 days: 1


## Had visits in last 5 days: 1


## Archive Time Last Started: 1609118712


## Archive Time Last Finished: 1609118817


## Num invalidations: 0 queued, 0 in progress


## User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0


## Browser Language: de,en-us,en


## Anonymize Referrer: 


## Do Not Track enabled: 0

@sgiehl any idea how this might happen?

@mstenz is maybe the geoip2 database removed somehow? Can't think of another reason why it should automatically disable the provider 🤔

i have just downloaded the file again. it is stored in misc folder and there is no antivirus (except from Windows Defender) installed on the system that is able to delete the file. i don't think there is any other processes on the system that would potentially delete any file. Let me watch the file and i will give you an update on this.

Hi,
i found that every day sometimes near midnight the file get deleted. Please see this file action. I found out that when activing geoip2php the first time there is a task created for the next day

DEBUG GeoIp2[2021-01-06 01:46:05 UTC] [60e2a] Rescheduling task and setting first run for tomorrow Piwik\Plugins\GeoIp2\GeoIP2AutoUpdater.update

I have now changed the schedule of this task to run in the next minutes, i assume the file again get deleted.

So it first get deleted, but not recreated, and subsequent accesses to the file then is failing. Unfortunately i had an issue with the debug-log today and there was nothing in at that time. maybe there is an error in the updating script on Windows? Not sure.
Any way I can debug this further?

ok. I found out that the

unlink($oldDbFile);

in GeoIP2AutoUpdater.php arround line 320 is the problem. When i uncomment this line everything works as expected and the file get replaced.
My assumption is, that the file is somehow locked becuase it was access by the php.exe process before. then the copy is done as expected, but because it is marked as "DELETE PENDING", as soon the php.exe process is away the file get deleted.
From the php documentation

On Windows, it is now possible to unlink() files with handles in use, while formerly that would fail. However, it is still not possible to re-create the unlinked file, until all handles to it have been closed.

I think the update process for Windows machines need to be re-thought completely to make it more stable and really working.

Interesting @mstenz thanks for finding this.

@sgiehl do you have a windows with a running Matomo installation maybe? Any chance you could reproduce this? I wonder if eg https://github.com/matomo-org/matomo/blob/4.1.1-b2/core/Http.php#L108 is a problem and keeps the file handle open. But doubt it would be the specific issue cause it should be first downloaded through HTTP into a tmp dir.

But doubt it would be the specific issue cause it should be first downloaded through HTTP into a tmp dir.
If I understand completely the problem is only if the file is exactly the same. It get download to the tmp dir without any problem. But because the $oldDbFile is first deleted and then replaced with new file from tmp directory Windows does not delete it directly when the command is executed, only when php.exe is closed.
first the file get downloaded to tmp, then it uses unlink and the target file get now deleted, then it tries to move the file (which fails) it goes to the next command which copy the file instead, but because move failed windows markes the file as "DELETE PENDING" and as soon php.exe finishes Windows deletes the file again (even this is not wat was expected) . This is what I understand from my debuggings.

But you are right. The http function in core is also faulty as it doesnt close it, its just no problem because the file is not needed after php.exe is finished.

@tsteur No, don't have set up PHP on windows atm. But could try doing that in a VM

Sounds good to like time restrict maybe max 2 hours or so in order to see if we can reproduce it.

Just set up a WAMP environment. Running the geoip update with an existing file always results in a deleted file. There are no other processes accessing the file. So it seems not possible to remove the file within the process. Need to check if there is a simple possibility to circumvent this

The ideas i have for preventing this and make it working both with Linux and windows:

• Do not replace the file, but always have a new file (ex. DB-IP-YYYYMMDD.mmdb) and only after successfully update delete the old file and update a config record with the current file name) - this is my personal favorite as it prevents parallel tasks that uses the file for processing while the update is task is running
• split the downloading, deletion and copy of the file with different tasks/processes

👍 adding it into the milestone

If I understand things correctly it should be maybe fixable that all file handles to it are closed? But not sure where it's left open (maybe the Geo IP lib or so)

as the move fails. i assume there is a bug in php and php itself does not close the handle. with would be possible with fopen and so on to rebuild the move command but I do not think thats worth the effort. in my comment before with the screenshot you see that the file is opened 7 times but only closed 3 times. so there are 4 handles that are not closed.

I think you can do a "Fast workarround" as i have did and just coment out the unlink line as this fixes the problem for both windows and linux.

@mstenz are you able to check if the changes of #17085 are fixing the issue for you?

@sgiehl it works for me