No progress count

[sdnian 6]

In client tasks page, the field 'PROGRESS' is empty. Like the screenshot in the below:

 

 

If I select any one of these client tasks then choose 'Show successful', 'Show failed'... there are history execution records in there.

 

How fix it?

 

ERA Server v6.4.304.0

ERA Web Console v6.4.266.0

OS: Ubuntu 16.04.1 LTS

MySQL 5.7.13

 

Thank you.

[tbsky 11]

In client tasks page, the field 'PROGRESS' is empty. Like the screenshot in the below:

 

era.png

 

If I select any one of these client tasks then choose 'Show successful', 'Show failed'... there are history execution records in there.

 

How fix it?

 

ERA Server v6.4.304.0

ERA Web Console v6.4.266.0

OS: Ubuntu 16.04.1 LTS

MySQL 5.7.13

 

Thank you.

 

hi:

   my ERA/web console version is the same as yours. but OS is rhel 7.2 with MySQL 5.6.  the progress field is fine. have you tried reboot ERA server?

 

   by the way, can MySQL 5.7 use with ERA 6.4 now? I remember in ERA 6.3, Eset said only MySQL 5.6 will work correctly.

Edited September 12, 2016 by tbsky

[MartinK 378]

Hello, version of MySQL database should be fine, especially in case all other functionality works, but you are right that there was bug in MySQL that affected functionality of ERA -> it was resolved in quite recent MySQL version 5.7.13.

What is version of AGENT that this tasks were executed on? What is the version history of SERVER - have you upgraded from previous version of ERA?

 

We had a problem with progress bars in previous releases, where only known workaround was to perform modification of database state, i.e.:

1. stop SERVER service
2. Modify database as described in my older post.
3. restart SERVER service

it should take no more than few minutes until progress counts are recalculated in case this was the source of your problems.

[sdnian 6]

Hello, version of MySQL database should be fine, especially in case all other functionality works, but you are right that there was bug in MySQL that affected functionality of ERA -> it was resolved in quite recent MySQL version 5.7.13.

What is version of AGENT that this tasks were executed on? What is the version history of SERVER - have you upgraded from previous version of ERA?

 

We had a problem with progress bars in previous releases, where only known workaround was to perform modification of database state, i.e.:

1. stop SERVER service
2. Modify database as described in my older post.
3. restart SERVER service

it should take no more than few minutes until progress counts are recalculated in case this was the source of your problems.

 

The server has running several months. I think the first version is 6.2, because I remember that it had been upgraded twice. (6.2 -> 6.3 -> 6.4)

Most Agent are 6.4.283.

 

And I've try to do your workaround, but no luck. The 'PROGRESS' is still empty. And the 'THREATS' show an error number now. 

 

A few minutes later, the error number in the THREATS is disappear.

Edited September 13, 2016 by sdnian

[MartinK 378]

That is very strange. Did it work in the history or never? It was added in ERA 6.3 if I recall correctly. It fails the same way for all client tasks? Are there any errors in SERVER's trace.log, especially from service startup?

Could you also provide output of queries described in my another post? It should help us check whether previous "workaround" actually worked.

[sdnian 6]

That is very strange. Did it work in the history or never? It was added in ERA 6.3 if I recall correctly. It fails the same way for all client tasks? Are there any errors in SERVER's trace.log, especially from service startup?

Could you also provide output of queries described in my another post? It should help us check whether previous "workaround" actually worked.

 

 

I've take a look Server's trace.log, but I don't find out any obvious error. Or could you take a look. 

trace.log

 

Here is another query output:

 

# mysql --host=localhost --user=root --password era_db --execute 'SELECT * FROM tbl_etl_event_csn; SELECT MAX(CSN) FROM tbl_log_task_client_event;'

Enter password: 

+----------------+----------------------+----------+

| plan_name      | table_name           | last_csn |

+----------------+----------------------+----------+

| sp_clientTasks | tbl_client_task_aggr |   139021 |

+----------------+----------------------+----------+

+----------+

| MAX(CSN) |

+----------+

|   139021 |

+----------+

 

This server has run for several months. I can confirm this issue didn't happened before. But I can't remember when happened. It been happened for a while. The OS (Ubuntu) been upgraded from 14.04 to 16.04 about two months ago. MySQL also been upgraded from 5.5.x to 5.7.13. Maybe it cause the issue since that time. 

[MartinK 378]

There are no relevant records in trace.log and result of query is correct (=as expected). Unfortunately I am not able to find out what could be problem - my guess is that there may be another issue (unknown to us) with MySQL 5.7 that was not fixed in 5.7.13 release, but it is almost impossible to confirm without more data. Attempts to replicate this issue were not successful -> my recommendation is to open support ticket with reference to this forum topic, it may take more time but there is a chance similar issue was reported previously.

[sdnian 6]

Okay, MartinK. Thanks for you help. I'll open support ticket to ask for help.

[sdnian 6]

I've open support ticket one week ago. But I didn't get any feedback from ESET until now. I try to send a email to ask. But the system repay me it was closed already. Are you kidding me? 

 

By the way.. I've installed ERA 6.4 in a new Ubuntu 16.04/MySQL 5.7.15.. It has the same problem. So I think that is a bug.