Linux
Centos 6.

Also, the verbose level should be more useful to debug this problem

Any status on this? Would be helpful to have this functionality working!

Such behavior documented in man files and --help output of zabbix_sender binary. It will be converted to ZBXNEXT issue.

Hi

Will this fix be available in 4.0 LTS?

cherts , currently, it's planned for 4.2+ only. But you would be able to use Zabbix sender 4.2 with Zabbix server 4.0 without any issues as far as I see it.

Well, you understand that using zabbix-agent version 4.0 and zabbix-sender 4.2+ with this feature is absurd.

It's like driving a  Zaporozhets with a engine Mercedes

cherts , what's wrong with that?

If you are using a DEB or RPM based Linux distribution, then using 2 versions of packages (zabbix-agent 4.0) and (zabbix-sender 4.2) on one server at the same time is not a good idea. I want to use the LTS version of zabbix and that it has all the necessary functionality.

(9) In sender_threads_wait() on Windows WaitForMultipleObjectsEx() is used to wait for all data-sending threads to finish, then it follows with WaitForSingleObject() for each thread in zbx_thread_wait(). Is that known to be a good solution - one WaitForMultipleObjectsEx() and then WaitForSingleObject() for every thread ?

Also - is it a good idea to use WaitForMultipleObjectsEx(..., ..., ..., INFINITE, ...) - i.e. no timeout at all ? Maybe it is better to set a long timeout. I'm afraid of deadlocks that infinite waiting can cause and user might have to intervene manually or even reboot the Windows server because of Zabbix agent.

<viktors.tjarve> The logic of calling one WaitForMultipleObjectsEx() and then WaitForSingleObject() for every thread is used in other places. The research to find out if that is the correct and the best approach I think is out of scope for this task. Maybe a DEV ticket should be created for this.
As for the INFINITE timeout - when the TCP connection is created for each thread a default socket timeout is set - GET_SENDER_TIMEOUT. This timeout is 60 seconds and all communication operations has to be completed during this time period or thread will exit with FAIL status.
CLOSED

We have noticed a strange error when zabbix_sender reads input values from file and runs under Valgrind on Linux.

The input file has 600 records.
The 1st batch of 250 records is sent as expected.
At he beginning of the 2nd batch of 250 records the current file position is corrupted (it is set 71 bytes backwards), it results in a corrupted record sent to server.
At he beginning of the 3rd batch of 250 records the current file position is again corrupted (it is set 6765 bytes backwards), as a result a number of records are sent to server twice.

Without Valgrind it works without error.

It has something to do with fork to send data in a separate process.
No actual sending is required, it happens even with "empty" function after fork in child process:

static ZBX_THREAD_ENTRY(send_value, args)
{
 _exit(SUCCEED);
}

Logging the current position, reported by ftell() shows corruption.
Saving the position before fork() with ftell() and restoring it with fseek() does not solve the issue (although produces different error).
Child process does not use the inherited input stream, it cannot close it because the file stream is not passed in arguments).

Added the somewhat unusual error message when using Zabbix sender compiled with TLS support to send data to Zabbix server/proxy compiled without TLS to TLS troubleshooting documentation - 3.0, 4.0, 4.2.

Sender side:

...End of zbx_tls_connect():FAIL error:'connection closed by peer'
...send value error: TCP successful, cannot establish TLS to [[localhost]:10051]: connection closed by peer

Released in:

• 4.2.0rc1 r91025, r91090

Updated documentation:

• What's new
• Zabbix sender
• Manpage