What does the "GZ error -5" mean in the Symantect Reporter, version 9.1.x Journal?


Article ID: 167209


Updated On:




I'm using the Symantec Reporter client to connect to Reporter,  but I am seeing a GZ error - 5  in the journals. What do they mean?

Using the techniques to discover journal errors in Reporter,  outlined in KB3460,  I can see that my streaming log source connection is showing a GZ error -5.  What does this mean?



With the streaming configuration ( Symantec reporter client ) the ProxySG sends gzip'd access log data in many small gzip segments which are only a few hundred to a couple thousand bytes per segment. These segments never appear as a file on the REporter server, but , rather, get directly injected into the database as soon as they arrive. A "Z_BUF_ERROR (-5)" typically means the ProxySG sent a gzip byte stream that did not begin with a proper gzip header. This error is generally only seen when the ProxySG re-creates a broken SGP connection with Reporter, and suddenly, and unexpectedly for Reporter, begins sending the rest of a gzip segment that was originally started right at the end of the previous closed connection.

NOTE: As the frequency of TCP connections being created and closed increases, there is a greater chance you will see this error.

Reporter, version 9.X,  will forgive the first gzip failure but, as it is virtually impossible to start up in the middle of a gzip stream and begin deflating the rest of the encoded byte stream, it cannot forgive any other breaks in the stream.    Thus, Reporter must search the byte stream for the next gzip segment header, tossing any data that was in the remainder of the decapitated segment. The -5 error lets everyone know that Reporter has had to drop a small amount of access log data, in order to catch up with the gzip segments. The older version of Reporter- version 8.x- had the exact same logic, only it stayed quiet about the dropped data and forgiven error. Once the next header is found, the continuing byte stream containing multiple gzip segments will be continuously deflated without further incident.

 NOTE:  Reporter 9.2, which is in open beta right now, will only forgive an initial gzip error if it occurs in the first packet after the connection is established.)

Here's an example of the error we see in the journal:

BCRJ:2009-09-24 16:02:50 (4abb27aa) ALW.ERRO.LOGSO
   Unzip log source 'BCLOG:ProxySG1' failed with GZ error -5


The coresponding event log message on the SG is:

2009-11-06 03:00:00-08:00PST  "Access Log Bluecoat Reporter (main): Closing TCP/IP connection."  0 E0000:96   ../alog_stream_custom.cpp:173
2009-11-06 03:00:00-08:00PST  "Access Log Bluecoat Reporter (main): Connecting to primary server"  0 E0000:96   ../alog_stream_bc_reporter.cpp:371
2009-11-06 03:00:00-08:00PST  "MSG_TYPE_ERROR in Reporter's connection ack, error code =1."  0 E0008:64   ../alog_stream_bc_reporter.cpp:531
2009-11-06 03:00:00-08:00PST  "Access Log Bluecoat Reporter (main): Closing TCP/IP connection."  0 E0000:96   ../alog_stream_custom.cpp:173
2009-11-06 03:00:00-08:00PST  "Access log (main): Log uploading failed.  Remote filename: Not Applicable size: 0 KB."  0 E0008:1 Mailed ../alog_manager.cpp:2277
2009-11-06 03:01:00-08:00PST  "Access Log (main): Unable to connect to remote server for log uploading"  0 E0008:1   ../alog_facility_impl.cpp:2725


There are two probable causes of this error:

1: If this GZIP occurs at daily intervals when the "rotate" trigger is scheduled at the SG, then it's a known issue, and can be solved by upgrading your SG operating system.  Please call support, and mention this KB article, for the exact version of SG you need. 

 2: The second cause of this connection oscillation is caused by a corrupt gzip byte stream. The ProxySG saves its access log data locally while the connection to Reporter is down. I have seen occasions where once a stable connection is made to Reporter, the accrued gzip data being sent by the ProxySG is no longer correct. In this case, reporter forgives any decapitated segment with a -5 journal message (strike 1), but the continuing corrupted byte stream coming from the ProxySG then causes the Z_DATA_ERROR (-3) error (strike 2). At this point, it is Reporter forcing the connection to close due to corrupt data. The journal messages are clear about which side caused the connection to close. As long as the ProxySG keeps sending corrupt gzip data, the journal will be full of the connect/error -5/error -3/fatal-close messages. More details on the  GZ error -3  is documented in 000011659

NOTE: For reasons why you might see a GZip error on a FTP log source, see 000013828