I have the same problem

Me too, after upgrade from zabbix 5.4 to 6.0

Hello!

Can you give more details, which exact template you're unable to import?

Is it some specific template or all?

I am not sure if it is impacted with all templates, I tried with this one (template_app_vmware.6.0.yml)

I tested and it works well here.

How long did you wait for the import to finish?

Have you upgraded zabbix from 5.4 to 6.0?

It just stuck while importing:

Yes, this installation is upgraded from 5.2->5.4->6.0

Do you see anything in the web server/php logs?

What DB backend are you using?

In logs, there is nothing special but maybe you will tell me what should I look for?

Server version: 10.6.7-MariaDB-1:10.6.7+maria~bionic mariadb.org binary distribution - upgraded too

Please run these commands on DB:

show create database zabbix;
show create table hosts;

show create database zabbix

 
show create table hosts

Have you tested if the same problem happens on a new installation?

You could do that by creating a new DB on the same DB host and then pointing frontend to it. You don't even need server to test template import.

Same issue here. To make the import work i had to increase the value of 

php_value[memory_limit] = 128M

To

php_value[memory_limit] = 1G

in the file

/etc/php-fpm.d/zabbix.conf

and restart the php-fpm service.

I've tried with 256M and 512M values but it didn't help.

this is pretty clear doing a status of php-fpm service during the template import

systemctl status  php-fpm.service
● php-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2022-02-24 22:35:16 CET; 10min ago
 Main PID: 951230 (php-fpm)
   Status: "Processes active: 1, idle: 17, Requests: 4935, slow: 0, Traffic: 1.2req/sec"
    Tasks: 19 (limit: 50370)
   Memory: 523.5M
   CGroup: /system.slice/php-fpm.service
           ├─951230 php-fpm: master process (/etc/php-fpm.conf)
           ├─951231 php-fpm: pool www
           ├─951232 php-fpm: pool www
           ├─951233 php-fpm: pool www
           ├─951234 php-fpm: pool www
           ├─951235 php-fpm: pool www
           ├─952379 php-fpm: pool zabbix
           ├─952430 php-fpm: pool zabbix
           ├─952755 php-fpm: pool zabbix
           ├─952853 php-fpm: pool zabbix
           ├─952860 php-fpm: pool zabbix
           ├─952866 php-fpm: pool zabbix
           ├─952936 php-fpm: pool zabbix
           ├─952949 php-fpm: pool zabbix
           ├─953819 php-fpm: pool zabbix
           ├─953821 php-fpm: pool zabbix
           ├─953896 php-fpm: pool zabbix
           ├─953902 php-fpm: pool zabbix
           └─953971 php-fpm: pool zabbix

When I created a new database on my Zabbix server, the frontend stops running. I have changed all required parameters but... it's weird. Back to the previous database setting - start working again.

I have installed php7.4-fpm service, but there is no /etc/php-fpm.d/zabbix.conf file.

I have increased memory_limit settings to 1G in /etc/php/7.4/apache2/php.ini but nothing has changed, still can not import the template.

Anyway, on the fresh installation of Zabbix 6.0 (new Ubuntu, Zabbix, MariaDB packages), the template can be imported without any issue.

php_value[memory_limit] = 1G

screenshot taken during import

I do not have /etc/php-fpm.d/zabbix.conf file, will it be the same to change it into /etc/php/7.4/apache2/php.ini?

I have deleted an old VMWare template from zabbix and imported a new one (for 6.0), it works. The template has been imported.

if /etc/php-fpm.d/zabbix.conf is used by default depends on what OS it's installed on.

I am currently not able to reproduce the problem

/etc/php/7.4/fpm/pool.d/zabbix-php-fpm.conf

this edit does not fix the bug

set memory_limit = 1G in /etc/php/7.4/fpm/php.ini 

it's solved problem for me.

set memory_limit = 1G in /etc/php/7.4/fpm/php.ini 

didn't help me

Had same problem, Ubuntu 20.04, Zabbix 6.0.0 (upgraded 4.0 - 5.0 - 6.0)

FPM memory limit 1G fixed the problem.

@SartuS: Did you run systemctl restart php7.4-fpm after changing the config?

yes

Same issue ( Upgrade from 5 to 6.0.1) , Increase of the PHP Memory to 1G didn't fix it

Same issue here while attempting import of template_fortinet_all_discovery

Set php_value[memory_limit] = 1G and restarted php7.4-fpm, this did not fix the issue.

Ubuntu 20.04 LTS, zabbix 6.0 (upgraded), php7.4

Hi Ben M and Onkel, 

1G is a value that is ok for my env but it could not be for yours.

Have you tried to increase the value to 2G while monitoring, during the import, how much memory the process is consuming?

I suggest to leave at 1G at first, run the import, and monitor the process ram usage during the import (systemctl status php7.4-fpm or ystemctl status  php-fpm it depends on your OS) to see if the problem is the memory limit. If the memory hits the 1G then try to increase the value to 1.5 or 2G and restart the service and try again.

Alan

Thanks Alan; I tried another import, this time watching the process (watch systemctl status php7.4-fpm) but it never changed from 14.8M. So I might be running up against a different issue than what you saw.

Just to make sure, I changed the memory limit to 2G, restarted the service, re-attempted import, but no luck.

To note, I do not show the same zabbix process running under fpm:

     CGroup: /system.slice/php7.4-fpm.service
             ├─1228379 php-fpm: master process (/etc/php/7.4/fpm/php-fpm.conf)
             ├─1228397 php-fpm: pool www
             └─1228398 php-fpm: pool www

And my config file is in a different location: /etc/zabbix/php-fpm.conf

I'm hitting the same problem. Some info that could be useful for troubleshooting:

• It happens un Postgres as well
• It DOES NOT happen with an empty database/clean installation
• IT has something to do with triggers: importing a template without triggers works fine
• When the import is "stuck" the database load skyrockets
• The culprit seems to be this query: " SELECT f.functionid,f.itemid,f.name,f.parameter FROM functions f WHERE (f.functionid IN (12128,12129,12130,12131,12132,..... <endless> amount of IDs..."

I found that changing the limit in include/db.inc.php, line 624, from

  $MAX_NUM_IN = 950

to

  $MAX_NUM_IN = 9500

let me access the latest data of a host which has more than 200 items a lot quicker.

This procedure is the same used to build the SELECT...IN which Cristian Mammoli talks about above, and should help therefore the import process.

It still takes a lot, on our system (6.0.2, on PostgreSQL 13), but it completes. I had to raise the various timeouts above 10 minutes, though, to not have PHP interrupt the process or the browser give up.

Hope this helps, in the meantime

I have the same issue with Zabbix 6.0.2. These are our components:

timescale/timescaledb:2.6.0-pg14 
zabbix/zabbix-server-pgsql:alpine-6.0.2
zabbix/zabbix-web-nginx-pgsql:alpine-6.0.2
zabbix/zabbix-proxy-sqlite3:alpine-6.0.2

On our productive system I cannot import templates anymore. As mentioned here the problems are the triggers.

In my case also discovery rules get stuck at import.

I have put the php.ini settings mentioned here and the db.inc.php setting. Nevertheless so far I had no success.

To test this I have cut down a template until the first trigger. Without the trigger everything else gets imported.

With the first trigger the systems gets stuck. How can this be fixed?

I want to import this template:

https://git.zabbix.com/projects/ZBX/repos/zabbix/browse/templates/db/mssql_odbc?at=release/6.0

For my case I could fix the issue with this setting for the web container:

 --env ZBX_MEMORYLIMIT=1G 

I stuck with MySQL by ODBC too (https://www.zabbix.com/integrations/mysql#mysql_odbc).

No success with any solutions

I have verified that this problems exists when the template has any TRIGGERS defined. No triggers and the template imports. 

I have the same issues, and can confirm that it is certanly TRIGGER related. 

Removing all triggers from the .yaml file, and the import was successful. 

After importing the template without the triggers, I tried to import the original (with triggers) again. That did not help unfortunately. Also unchecking every box, except the triggers did not resolve the issue.

Fixed in:

• 6.0.3rc1 a7a6802457e
• 6.2.0alpha1 6bafb0ea32b

I am facing similar issue with 6.0.13 after upgrading from 5.4 but with Maps. Neither yaml nor xml maps that were exported on 5.4 can be imported on 6.0.13.
It just hangs after selecting the file and clicking import. After deleting all triggers I was able to import the map. So it seems that the issue has not been fixed at least for maps