Welcome to OCS Inventory NG community support, where you can ask questions and receive answers from other members of the community.

Please ask questions only in English or French.

Release 2.11.1 available

The official documentation can be found on http://wiki.ocsinventory-ng.org. Read it before asking your question.

Inventories not received after upgrade to 2.4


Since upgrading our OCS to v2.4, no agents are able to successfully send their inventories.

I am seeing errors in my /var/log/httpd/error_log as follows:

[Tue Feb 06 08:57:42 2018] [error] [client] Can't call method "do" on an undefined value at /usr/lib/perl5/site_perl/5.8.8/Apache/Ocsinventory/Server/System.pm line 189.\n
[Tue Feb 06 08:57:52 2018] [error] [client] Can't call method "do" on an undefined value at /usr/lib/perl5/site_perl/5.8.8/Apache/Ocsinventory/Server/System.pm line 189.\n

Line 189 of the script is:


I hit this problem last time I upgraded, but it was fixed by updating our DB access details: http://ocsinventory12.rssing.com/browser.php?indx=50766537&item=1567

This time, however, our details are correct, but we still have the problem.

Please can someone guide me on where to start looking to fix this problem?

Thank you.


System Details:

OS Name : Linux x86_64
Version : 2.6.18-419.el5.centos.plus
RAM installed : 7979 MB
CPU : Quad-Core AMD Opteron(tm) Processor 1354
PHP Version : 5.6.30
Web Server : Apache
Database Server : MySQL Community Server (GPL) by Remi version 5.5.54
Version OCSReports: 2.4

in OCS Inventory NG server for Unix by (470 points)
edited by

4 Answers

0 votes
I also have this problem, installed the 2.4 version of OCS, using a previous database of 2.1 version.

Everything works nicely, but I can't receive the inventory from agents.

Username and password of database works fine.

I can write data from the interface of OCS reports to my database.

Creating new tags or updating and doing other things, but no new inventories.

From /var/log/ocsinventory-server/activity.log I have this:

Mon Feb  5 14:55:55 2018;27761;318;PANOVA-2018-02-02-17-16-18;;OCS-NG_WINDOWS_AGENT_v2.3.1.1;session;missing
Mon Feb  5 14:55:55 2018;27761;114;PANOVA-2018-02-02-17-16-18;;OCS-NG_WINDOWS_AGENT_v2.3.1.1;inventory;no_session
Mon Feb  5 14:55:55 2018;27761;104;PANOVA-2018-02-02-17-16-18;;OCS-NG_WINDOWS_AGENT_v2.3.1.1;inventory;incoming
Mon Feb  5 14:55:55 2018;27761;515;PANOVA-2018-02-02-17-16-18;;OCS-NG_WINDOWS_AGENT_v2.3.1.1;end;error
Mon Feb  5 14:56:07 2018;13082;103;PANOVA-2018-02-02-17-16-18;;OCS-NG_WINDOWS_AGENT_v2.3.1.1;prolog;new_deviceid
Mon Feb  5 14:56:07 2018;13082;100;PANOVA-2018-02-02-17-16-18;;OCS-NG_WINDOWS_AGENT_v2.3.1.1;prolog;accepted
Mon Feb  5 14:56:07 2018;13082;311;PANOVA-2018-02-02-17-16-18;;OCS-NG_WINDOWS_AGENT_v2.3.1.1;session;started
Mon Feb  5 14:56:14 2018;25101;318;PANOVA-2018-02-02-17-16-18;;OCS-NG_WINDOWS_AGENT_v2.3.1.1;session;missing
Mon Feb  5 14:56:14 2018;25101;114;PANOVA-2018-02-02-17-16-18;;OCS-NG_WINDOWS_AGENT_v2.3.1.1;inventory;no_session
Mon Feb  5 14:56:14 2018;25101;104;PANOVA-2018-02-02-17-16-18;;OCS-NG_WINDOWS_AGENT_v2.3.1.1;inventory;incoming
Mon Feb  5 14:56:14 2018;25101;515;PANOVA-2018-02-02-17-16-18;;OCS-NG_WINDOWS_AGENT_v2.3.1.1;end;error
Tue Feb  6 07:57:57 2018;4039;103;dsvadriano-2018-02-06-07-57-56;;OCS-NG_unified_unix_agent_v2.0.5;prolog;new_deviceid
Tue Feb  6 07:57:57 2018;4039;100;dsvadriano-2018-02-06-07-57-56;;OCS-NG_unified_unix_agent_v2.0.5;prolog;accepted
Tue Feb  6 07:57:57 2018;4039;311;dsvadriano-2018-02-06-07-57-56;;OCS-NG_unified_unix_agent_v2.0.5;session;started
Tue Feb  6 07:58:02 2018;4043;318;dsvadriano-2018-02-06-07-57-56;;OCS-NG_unified_unix_agent_v2.0.5;session;missing
Tue Feb  6 07:58:02 2018;4043;114;dsvadriano-2018-02-06-07-57-56;;OCS-NG_unified_unix_agent_v2.0.5;inventory;no_session
Tue Feb  6 07:58:02 2018;4043;104;dsvadriano-2018-02-06-07-57-56;;OCS-NG_unified_unix_agent_v2.0.5;inventory;incoming
Tue Feb  6 07:58:02 2018;4043;528;dsvadriano-2018-02-06-07-57-56;;OCS-NG_unified_unix_agent_v2.0.5;accountinfos;missing
Tue Feb  6 07:58:02 2018;4043;515;dsvadriano-2018-02-06-07-57-56;;OCS-NG_unified_unix_agent_v2.0.5;end;error
by (550 points)
0 votes

I have found the answer to our problem.

Even though I updated /etc/ocsinventory/ocsinventory-reports/dbconfig.inc.php and /etc/httpd/conf.d/z-ocsinventory-server.conf, we found that /etc/httpd/conf.d/zz-ocsinventory-restapi.conf also has to be updated.

It appears that the DB creds in /etc/httpd/conf.d/z-ocsinventory-server.conf get replaced by /etc/httpd/conf.d/zz-ocsinventory-restapi.conf, even though we're not using the API.

by (470 points)
0 votes
Yes, I've checked this file too, both have the same dbuser and dbpass but keep the same error. :-(

I'm still searching for a solution.
by (550 points)
0 votes
Great, searching for more log info, I've found this:


Then I found this too:


So, I updated the table networks with the command:


Now the machines (Linux or Windows) can send the inventories.

by (550 points)
Powered by Question2Answer