Difference between revisions of "Non-ASL error messages"

From Atomicorp Wiki
Jump to: navigation, search
m (Directive 'UseDNS' is not allowed within a Match block)
m
Line 1: Line 1:
 
This page is provided as a courtesy to our customers for errors with non-atomicorp products and potential solutions to these errors.
 
This page is provided as a courtesy to our customers for errors with non-atomicorp products and potential solutions to these errors.
 +
 +
= mysql errors =
 +
 +
== Aborted connection 12345 to db: 'tortix' user: 'tortix' host: 'localhost' (Got an error reading communication packets) ==
 +
 +
When a client or application unable to connect to mysql, the mysql server increments the Aborted_connects status variable. Unsuccessful connection attempts can occur for the following reasons:
 +
 +
*ASL is attempting to connect to the tortix database, but has no privileges to access the database
 +
*ASL is configured to use the wrong password to log into its database
 +
*It takes more than connect_timeout seconds to obtain a connect packet.  (This is the most common cause)
 +
 +
This can also occur if the mysql connection is improperly disconnect or is terminated, in which case the mysql server increments the Aborted_clients status variable, and logs an Aborted connection message to the error log. The cause can be any of the following:
 +
 +
*The client connection to the mysql server has been sleeping more than wait_timeout or interactive_timeout seconds without issuing any requests to the server.
 +
*A component in ASL that writes to the database was abruptly terminated in the middle of a data transfer.
 +
*The max_allowed_packet variable value is too small or queries require more memory than you have allocated for mysqld.
 +
*Some Linux Ethernet drivers have a bug that can cause connections to abruptly close. You should test for this bug by transferring a huge file using FTP between the client and server machines. If a transfer goes in burst-pause-burst-pause mode, you are experiencing a Linux duplex syndrome. Switch the duplex mode for both your network card and hub/switch to either full duplex or to half duplex and test the results to determine the best setting.
 +
*A problem with the thread library that causes interrupts on reads.
 +
*Badly configured TCP/IP.
 +
*For remote mysql servers, this can also occur does to network problems, and bad hardware include but not limited to hubs, switches, cables, and so forth. This can be diagnosed properly only by replacing hardware.
 +
  
 
= sshd errors =
 
= sshd errors =

Revision as of 16:43, 13 June 2016

This page is provided as a courtesy to our customers for errors with non-atomicorp products and potential solutions to these errors.

Contents

mysql errors

Aborted connection 12345 to db: 'tortix' user: 'tortix' host: 'localhost' (Got an error reading communication packets)

When a client or application unable to connect to mysql, the mysql server increments the Aborted_connects status variable. Unsuccessful connection attempts can occur for the following reasons:

  • ASL is attempting to connect to the tortix database, but has no privileges to access the database
  • ASL is configured to use the wrong password to log into its database
  • It takes more than connect_timeout seconds to obtain a connect packet. (This is the most common cause)

This can also occur if the mysql connection is improperly disconnect or is terminated, in which case the mysql server increments the Aborted_clients status variable, and logs an Aborted connection message to the error log. The cause can be any of the following:

  • The client connection to the mysql server has been sleeping more than wait_timeout or interactive_timeout seconds without issuing any requests to the server.
  • A component in ASL that writes to the database was abruptly terminated in the middle of a data transfer.
  • The max_allowed_packet variable value is too small or queries require more memory than you have allocated for mysqld.
  • Some Linux Ethernet drivers have a bug that can cause connections to abruptly close. You should test for this bug by transferring a huge file using FTP between the client and server machines. If a transfer goes in burst-pause-burst-pause mode, you are experiencing a Linux duplex syndrome. Switch the duplex mode for both your network card and hub/switch to either full duplex or to half duplex and test the results to determine the best setting.
  • A problem with the thread library that causes interrupts on reads.
  • Badly configured TCP/IP.
  • For remote mysql servers, this can also occur does to network problems, and bad hardware include but not limited to hubs, switches, cables, and so forth. This can be diagnosed properly only by replacing hardware.


sshd errors

Directive 'UseDNS' is not allowed within a Match block

This occurs when sshd configuration has been modified to include Match blocks and the directive is not supported as part of the match. There is no way to explicitly end Match blocks (note: see solution 2 below for one way to work around this). From the sshd_config manual page:

If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file.

Solution 1:

Match blocks need to be at the end of the sshd_config file, and all global configuration options must occur before these Match blocks.

Solution 2:

Another option is to have a line with nothing but Match on it, which effectively matches everything and therefore is the same as 'ending' the block.

yum errors

Problem with the SSL CA cert (path? access rights?)

That means someone/something has corrupted or replaced the root CA cerificates your operating system uses to verify SSL cerificates. That means it either cant find them, access them or they have been modified/corrupted so that some or all of the root CAs certificates are missing. When this happens, yum cant confirm that SSL connections are valid. While this is an operating system level error, and something we'd advise you discuss with your OS vendor and/or hosting company, the following is the standard command to tell your OS to reinstall its SSL root CAs:

yum reinstall ca-certificates

If you are using any third party repos, we advise you disable them in case they are the source of this error. For example, if you are using EPEL:

yum --disablerepo="epel" reinstall ca-certificates

Note: You may need to disable additional repos, if those repos use SSL to download updates. yum will continue to fail as it tries to access repos that are accessed over SSL. Therefore, you will need to disable any repos that use SSL.

On some systems this may also be caused by an interrupted install of nss package updates from the OS vendor. Reinstallation of the nss packages may also be required:

yum reinstall nss*

If you would like our assistance with this OS level issue, we'd be happy to help you with and put a quote together for these services. Please contact support for a quote.

Personal tools