logrtitems from 2.0.11 to 2.0.12:
* On UNIX platforms a ''logrt'' item becomes NOTSUPPORTED if a directory where the log files are expected to be found does not exist (this is mentioned for clarification, there is no change from 2.0.11 to 2.0.12). * Unfortunately, on Microsoft Windows if a directory does not exist the item will not become NOTSUPPORTED (for example, if directory is misspelled in item key). Currently this is a limitation of agent (on 2.0.11 it caused NOTSUPPORTED). * An absence of log files for ''logrt'' item does not make it NOTSUPPORTED (on 2.0.11 it caused NOTSUPPORTED). * Errors of reading log files for ''logrt'' item are logged as warnings into Zabbix agent log file but do not make the item NOTSUPPORTED (on 2.0.11 it caused NOTSUPPORTED). * Zabbix agent log file can be helpful to find out why a ''log'' or ''logrt'' item became NOTSUPPORTED. Zabbix can monitor its agent log file except when DebugLevel=4. * Please note that even though performance of ''log'' and ''logrt'' item checks has been improved the limits on maximum number of log file records analysed and number of matching records sent to server in one check are not modified. For example, if a ''log'' or ''logrt'' item has //Update interval// of 1 second, by default the agent will not analyse more than 400 log file records and will not send more than 100 matching records to Zabbix server in one check. By increasing **MaxLinesPerSecond** parameter in agent configuration file or setting **maxlines** parameter in the item key the limit can be increased up to 4000 analysed log file records and up to 1000 matching records sent to Zabbix server in one check. If the //Update interval// is set to 2 seconds the limits for one check would be set 2 times higher than for //Update interval// 1 second. * Startup and shutdown scripts for Java gateway no longer hide error messages on startup. They now also detect stale PID files and should work in /bin/sh. * No more partial server/proxy configuration. Error checks have been added to the process of loading configuration from the database to avoid working with partial configuration. In case of a database error the server/proxy will continue working with existing configuration.