This section describes the most common error messages of syslog-ng OSE.

Destination queue full

Error message: Destination queue full, dropping messages; queue_len=’10000’, log_fifo_size=’10000’ count=’4’, persist_name=’afsocket_dd_qfile(stream,serverdown:514)’
Description: This message indicates message loss. Flow-control must be enabled in the log path. When flow-control is enabled, syslog-ng OSE will stop reading messages from the sources of the log statement if the destinations are not able to process the messages at the required speed. If flow-control is enabled, syslog-ng OSE will only drop messages if the destination queues/window sizes are improperly sized.
Solution: Enable flow-control in the log path. If flow-control is disabled, syslog-ng OSE will drop messages if the destination queues are full. Note that syslog-ng OSE will drop messages even if the server is alive. If the remote server accepts logs at a slower rate than the sender syslog-ng OSE receives them, the sender syslog-ng OSE will fill up the destination queue, then drop the newer messages. Sometimes this error occurs only at a specific time interval, for example, only between7:00AM and8:00AM or between16:00PM and17:00PM when your users log in or log off and that generates a lot of messages within a short interval.

For more information, see Managing incoming and outgoing messages with flow-control

Disk-queue record was still being processed when syslog-ng last stopped

Error message: Disk-queue record was still being processed when syslog-ng last stopped, this might indicate a crash caused by this specific record; filename=’/opt/syslog-ng/var/syslog-ng-00000.rqf’, pending_read_head=’4096’, pending_read_crash_count=’1’
Description: A reliable disk-buffer popped this record for processing, but the previous syslog-ng OSE run ended before it was acknowledged. This can happen after a crash or shutdown unrelated to the record itself, or because this specific record is the reason syslog-ng OSE keeps stopping.
Solution: No action is needed for a single occurrence. If this message keeps appearing for the same file across further restarts, the file will eventually be quarantined automatically, see Disk-queue quarantined after repeatedly crashing while processing the same record.

Disk-queue quarantined after repeatedly crashing while processing the same record

Error message: Disk-queue quarantined after repeatedly crashing while processing the same record; filename=’/opt/syslog-ng/var/syslog-ng-00000.rqf’, pending_read_crash_count=’3’
Description: The oldest unacknowledged record survived 3 consecutive syslog-ng OSE restarts without ever being acknowledged, so syslog-ng OSE assumes this specific record is the cause and stops retrying it. The queue file is renamed to .corrupted and a new, empty one is started, the same way a structurally corrupt queue file is handled.
Solution: The messages stored in the quarantined .corrupted file are not forwarded automatically. Use dqtool cat to inspect its contents if you need to recover the other messages stored in it.

Incoming frame larger than log_msg_size()

Error message: Incoming frame larger than log_msg_size(); log_msg_size=’65536’, frame_length=’103745’
Description: The receiving syslog-ng OSE source received an RFC 6587 frame whose declared message length exceeds its effective log-msg-size() limit. By default, the receiver rejects the oversized frame and closes the TCP or TLS connection. Repeated oversized messages can cause repeated reconnects and a growing sender-side queue.
Solution: Increase log-msg-size() on the receiving source to accommodate the largest expected forwarded message, including syslog headers and structured data. For example, log-msg-size(131072) accommodates the frame shown above. A source-specific value overrides the global setting. Reload the receiver configuration and verify that the error and connection drops stop. Increasing only the sender’s limit does not resolve this receiving-side error.

Alert unknown CA

Error message: SSL error while writing stream; tls_error=’SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca’
Description: This message indicates that the other (remote) side could not verify the certificate sent by syslog-ng.
Solution: Check the logs on the remote site and identify why the receiving syslog-ng OSE could not find the CA certificate that signed this certificate.

PEM routines:PEM_read_bio:no start line

Error message: testuser@thor-x1:~ cert_no_start_line/certs$ openssl x509 -in cert.pem -text unable to load certificate 140178126276248: error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:701:Expecting: TRUSTED CERTIFICATE
Description: The error message is displayed when using Transport Layer Security (TLS). The syslog-ng OSE application uses OpenSSL for TLS and this message indicates that the certificate contains characters that OpenSSL cannot process. The error occurs when the certificate comes from Windows and you want to use it on a Linux-based computer. On Windows, the end of line EOL character is different \r\n compared to Linux \n. To verify this, open the certificate in a text editor, for example, MCEdit. Notice the \^M characters as shown in the image below:
Figure 24: Example of OpenSSL character processing error
Solution: On Windows, save the certificate using UTF-8, for example, using Notepad++.

Windows Notepad is not able to save the file in normal UTF-8, even if you select it.

  1. In Notepad++, from the menu, select Encoding.
  2. Change the value from UTF-8-BOM to UTF-8.
  3. Save.
  • On Linux, run dos2unix cert.pem. This will convert the file to a Linux-compatible style.
  • Alternatively, replace the EOL characters in the file manually.

Updated: