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.