I'm having trouble running quick synchronization for my local collection of photos:
[Mon Nov 25 21:16:28.037193 2019] [php7:warn] [pid 519] [client 192.168.0.170:53875] PHP Warning: Error while sending QUERY packet. PID=519 in /var/www/include/dblayer/functions_mysqli.inc.php on line 141, referer: http://192.168.0.1:1000/admin.php
[Mon Nov 25 21:16:28.037296 2019] [php7:warn] [pid 519] [client 192.168.0.170:53875] PHP Warning: [mysql error 2006] MySQL server has gone away\nSHOW FULL COLUMNS FROM `piwigo_images` in /var/www/include/dblayer/functions_mysqli.inc.php on line 856, referer: http://192.168.0.1:1000/admin.php
[Mon Nov 25 21:16:28.037362 2019] [php7:error] [pid 519] [client 192.168.0.170:53875] PHP Fatal error: Uncaught Error: Call to a member function fetch_assoc() on bool in /var/www/include/dblayer/functions_mysqli.inc.php:220\nStack trace:\n#0 /var/www/include/dblayer/functions_mysqli.inc.php(355): pwg_db_fetch_assoc(false)\n#1 /var/www/admin/site_update.php(909): mass_updates('piwigo_images', Array, Array, 1)\n#2 /var/www/admin.php(309): include('/var/www/admin/...')\n#3 {main}\n thrown in /var/www/include/dblayer/functions_mysqli.inc.php on line 220, referer: http://192.168.0.1:1000/admin.php
[Mon Nov 25 21:16:28.037465 2019] [php7:warn] [pid 519] [client 192.168.0.170:53875] PHP Warning: [mysql error 2006] MySQL server has gone away\n\nREPLACE INTO piwigo_sessions\n (id,data,expiration)\n VALUES('C0A8bmu4nacd2dthtgm13t76ip69sa','pwg_device|s:7:\\"desktop\\";pwg_mobile_theme|b:0;pwg_uid|i:1;pwg_referer_image_id|s:6:\\"148600\\";need_update2.10.1|b:0;extensions_need_update|a:0:{}incompatible_plugins|a:1:{s:10:\\"~~expire~~\\";i:1574710904;}bulk_manager_filter|a:1:{s:9:\\"prefilter\\";s:14:\\"no_sync_md5sum\\";}',now())\n; in /var/www/include/dblayer/functions_mysqli.inc.php on line 856, referer: http://192.168.0.1:1000/admin.php
This happens in Debian Buster (I also replicated it on Stretch, but don't have the exact versions of packages here) running Piwigo 2.10.1 on apache2 2.4.38-3+deb10u3, PHP 7.3 7.3.9-1~deb10u1 and MariaDB 10.4.10-MariaDB-1:10.4.10+maria~bionic (it's running in separate container, built by MariaDB corp). The setup is generated from the Dockerfile in this repository.
The database currently has 89656 images. I did read the code a bit and it seems that it's probably not caused by the queries in this log, but perhaps the previous ones timing out? It does take some minutes for this to appear (I'll clock it the next time). I've tried tuning MariaDB wait_timeout, but that hasn't fixed the issue. Manually syncing smaller bits of the collection works okay though.
Let me know if there's more info I could supply you with, besides the missing time.
I'm having trouble running quick synchronization for my local collection of photos:
```
[Mon Nov 25 21:16:28.037193 2019] [php7:warn] [pid 519] [client 192.168.0.170:53875] PHP Warning: Error while sending QUERY packet. PID=519 in /var/www/include/dblayer/functions_mysqli.inc.php on line 141, referer: http://192.168.0.1:1000/admin.php
[Mon Nov 25 21:16:28.037296 2019] [php7:warn] [pid 519] [client 192.168.0.170:53875] PHP Warning: [mysql error 2006] MySQL server has gone away\nSHOW FULL COLUMNS FROM `piwigo_images` in /var/www/include/dblayer/functions_mysqli.inc.php on line 856, referer: http://192.168.0.1:1000/admin.php
[Mon Nov 25 21:16:28.037362 2019] [php7:error] [pid 519] [client 192.168.0.170:53875] PHP Fatal error: Uncaught Error: Call to a member function fetch_assoc() on bool in /var/www/include/dblayer/functions_mysqli.inc.php:220\nStack trace:\n#0 /var/www/include/dblayer/functions_mysqli.inc.php(355): pwg_db_fetch_assoc(false)\n#1 /var/www/admin/site_update.php(909): mass_updates('piwigo_images', Array, Array, 1)\n#2 /var/www/admin.php(309): include('/var/www/admin/...')\n#3 {main}\n thrown in /var/www/include/dblayer/functions_mysqli.inc.php on line 220, referer: http://192.168.0.1:1000/admin.php
[Mon Nov 25 21:16:28.037465 2019] [php7:warn] [pid 519] [client 192.168.0.170:53875] PHP Warning: [mysql error 2006] MySQL server has gone away\n\nREPLACE INTO piwigo_sessions\n (id,data,expiration)\n VALUES('C0A8bmu4nacd2dthtgm13t76ip69sa','pwg_device|s:7:\\"desktop\\";pwg_mobile_theme|b:0;pwg_uid|i:1;pwg_referer_image_id|s:6:\\"148600\\";need_update2.10.1|b:0;extensions_need_update|a:0:{}incompatible_plugins|a:1:{s:10:\\"~~expire~~\\";i:1574710904;}bulk_manager_filter|a:1:{s:9:\\"prefilter\\";s:14:\\"no_sync_md5sum\\";}',now())\n; in /var/www/include/dblayer/functions_mysqli.inc.php on line 856, referer: http://192.168.0.1:1000/admin.php
```
This happens in Debian Buster (I also replicated it on Stretch, but don't have the exact versions of packages here) running Piwigo 2.10.1 on apache2 2.4.38-3+deb10u3, PHP 7.3 7.3.9-1\~deb10u1 and MariaDB 10.4.10-MariaDB-1:10.4.10+maria\~bionic (it's running in separate container, built by MariaDB corp). The setup is generated from the Dockerfile in [this repository](https://github.com/mathieuruellan/docker-piwigo).
The database currently has 89656 images. I did read the code a bit and it seems that it's probably not caused by the queries in this log, but perhaps the previous ones timing out? It does take some minutes for this to appear (I'll clock it the next time). I've tried tuning MariaDB wait_timeout, but that hasn't fixed the issue. Manually syncing smaller bits of the collection works okay though.
Let me know if there's more info I could supply you with, besides the missing time.
<!-- github-sync-id:528353921 -->
The error is returned at 244 seconds after starting quick sync. So I'll better peruse my configuration for some 240 second timeout.
The error is returned at 244 seconds after starting quick sync. So I'll better peruse my configuration for some 240 second timeout.
<!-- github-comment-id:558462846 -->
Okay, so the problem appears to be that this loop takes too long time in my case so that the MySQL connection times out. I did a local quick and dirty fix for it by chunking this loop into parts and making a no-op query to the database between the chunks. If the chunking went all the way to the mass_updates call, it would neatly also checkpoint the metadata sync to the database. I could do a fix based on this idea.
But I'm not sure if this is the correct fix. I think the applicable MariaDB timeout should be wait_timeout, but that's 600s in the official distribution and making it even bigger doesn't seem to have an effect. Of course mine is a bit of extreme case to have the sync take this long, but still, I'd like it to work. Checkpointing it by chunked processing would also add to the resiliency.
I see @plegall has last been around site_update - any comments?
Okay, so the problem appears to be that [this loop](https://github.com/Piwigo/Piwigo/blob/master/admin/site_update.php#L854-L887) takes too long time in my case so that the MySQL connection times out. I did a local quick and dirty fix for it by chunking this loop into parts and making a no-op query to the database between the chunks. If the chunking went all the way to the mass_updates call, it would neatly also checkpoint the metadata sync to the database. I could do a fix based on this idea.
But I'm not sure if this is the correct fix. I think the applicable MariaDB timeout should be `wait_timeout`, but that's 600s in the official distribution and making it even bigger doesn't seem to have an effect. Of course mine is a bit of extreme case to have the sync take this long, but still, I'd like it to work. Checkpointing it by chunked processing would also add to the resiliency.
I see @plegall has last been around site_update - any comments?
<!-- github-comment-id:559882886 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I'm having trouble running quick synchronization for my local collection of photos:
This happens in Debian Buster (I also replicated it on Stretch, but don't have the exact versions of packages here) running Piwigo 2.10.1 on apache2 2.4.38-3+deb10u3, PHP 7.3 7.3.9-1~deb10u1 and MariaDB 10.4.10-MariaDB-1:10.4.10+maria~bionic (it's running in separate container, built by MariaDB corp). The setup is generated from the Dockerfile in this repository.
The database currently has 89656 images. I did read the code a bit and it seems that it's probably not caused by the queries in this log, but perhaps the previous ones timing out? It does take some minutes for this to appear (I'll clock it the next time). I've tried tuning MariaDB wait_timeout, but that hasn't fixed the issue. Manually syncing smaller bits of the collection works okay though.
Let me know if there's more info I could supply you with, besides the missing time.
The error is returned at 244 seconds after starting quick sync. So I'll better peruse my configuration for some 240 second timeout.
Okay, so the problem appears to be that this loop takes too long time in my case so that the MySQL connection times out. I did a local quick and dirty fix for it by chunking this loop into parts and making a no-op query to the database between the chunks. If the chunking went all the way to the mass_updates call, it would neatly also checkpoint the metadata sync to the database. I could do a fix based on this idea.
But I'm not sure if this is the correct fix. I think the applicable MariaDB timeout should be
wait_timeout, but that's 600s in the official distribution and making it even bigger doesn't seem to have an effect. Of course mine is a bit of extreme case to have the sync take this long, but still, I'd like it to work. Checkpointing it by chunked processing would also add to the resiliency.I see @plegall has last been around site_update - any comments?