[ZBX-2553] Simple check ignores server replies Created: 2010 Jun 15  Updated: 2017 May 30  Resolved: 2010 Jun 22

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Agent (G), Server (S)
Affects Version/s: 1.8.2
Fix Version/s: 1.8.3, 1.9.0 (alpha)

Type: Incident report Priority: Major
Reporter: Mark Eissler Assignee: Alexander Vladishev
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Centos 5.x.


Attachments: Text File net.c.patch    
Issue Links:
Duplicate
is duplicated by ZBX-2555 Simple check doesn't send correct sen... Closed

 Description   

I stumbled across this problem after deploying a new unified communications system... We've been having problems with the smtp service so I'll use that as an example.

The smtp process has been hanging and Zabbix has been reporting no problem with the service. In our environment, we run a Zabbix Agent daemon on each server and send requests to the agent. It seems that Zabbix is satisfied that it can connect to the smtp daemon and completely ignores the response (which should be "220" for smtp). This doesn't seem to be the intended outcome since simple.c defines expect parameters, for example:

else if(strcmp(service,"smtp") == 0)

{ if(port == 0) port=25; ret=tcp_expect(ip,port,NULL,"220","QUIT\n",&value_int); }

The problem here is the NULL parameter, which is translated as the "request" string. Once the parameters are handed to tcp_expect(), the following block results in a service up condition:

if( NULL == request )

{ *value_int = 1; }

That's not really what we want because the service can be running (as was in our case) and yet the server does not return a valid status. If tcp_expect looks for the "220" sent in the parameters, the function would properly return a failed state.

I have a patch that modifies tcp_expect to always look for the passed "expect" string and return status based on that. The proper behavior. If a "request" string has also been passed, then we send that first. The "sendtoclose" string is always sent at the end if the connection has been opened successfully.



 Comments   
Comment by Mark Eissler [ 2010 Jun 15 ]

The patch was produced with "diff -urNad", let me know if you need more context, etc.

Comment by Aleksandrs Saveljevs [ 2010 Jul 01 ]

Fixed in pre-1.8.3 in r13126.

Generated at Fri Mar 29 07:33:18 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.