-2

I have a Magento website on degitalocean.com and I am unable to login via SSH or SFTP. Almost every alternate day I'm facing this problem and I have to restart my droplet via digitalocean account to make website working. Few days ago it was giving MYSQL connectivity error which i resolved by increasing droplet RAM to 2GB and by creating SWAP file.

Can anyone please suggest solution for this issue? Also let me know if you want to see any code files.


I have added few lines from error.log please see if this can be help

 150808 10:18:38 [Note] Plugin 'FEDERATED' is disabled.
 150808 10:18:38 InnoDB: The InnoDB memory heap is disabled
 150808 10:18:38 InnoDB: Mutexes and rw_locks use GCC atomic builtins
 150808 10:18:38 InnoDB: Compressed tables use zlib 1.2.8
 150808 10:18:38 InnoDB: Using Linux native AIO
 150808 10:18:38 InnoDB: Initializing buffer pool, size = 128.0M
150808 10:18:38 InnoDB: Completed initialization of buffer pool
150808 10:18:47 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
150808 10:18:47  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
150808 10:18:49  InnoDB: Waiting for the background threads to start
150808 10:18:50 InnoDB: 5.5.38 started; log sequence number 976719446
150808 10:18:50 [Note] Server hostname (bind-address): '178.**.42.108'; port: 3306
150808 10:18:50 [Note]   - '178.**.42.108' resolves to '178.**.42.108';
150808 10:18:50 [Note] Server socket created on IP: '178.**.42.108'.
150808 10:19:01 [Note] Event Scheduler: Loaded 0 events
150808 10:19:01 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.38-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
150808 10:21:00 [Warning] IP address '221.211.62.106' could not be resolved: Name or service not known
150808 11:17:09 [Warning] IP address '115.238.245.12' could not be resolved: Name or service not known

My.cnf

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
#
# * Basic Settings
#
user        = mysql
performance_schema             = off
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address        = 127.0.0.1
#
# * Fine Tuning
#
key_buffer      = 32M
max_allowed_packet  = 16M
thread_stack        = 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover-options  = BACKUP
#max_connections        = 100
#table_cache            = 128
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit   = 1M
query_cache_size        = 32M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
#log_slow_queries   = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id      = 1
#log_bin            = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_binlog_size         = 100M
#binlog_do_db       = include_database_name
#binlog_ignore_db   = include_database_name
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet  = 256M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
socket      = /var/run/mysqld/mysqld.sock

[isamchk]
key_buffer      = 256M

#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/
manish
  • 1
  • 1

2 Answers2

4

Digital Ocean provides console access from the control panel. Use that to login when the system is down and gather information, When you have information use it to decide what to do. Anything else is guessing and with the information you have provided I guess Perseid Meteor shower.


Being structured and methodical in your approach is much better than flapping around wildly.

Personally I find Scientific Method (others call it something different) a wonderful tool to pull out of the system administration kitbag when diagnosing problems.

  1. What is the actual problem you're trying to solve ?

A service stops responding.

  1. So, now we know what the actual problem is we're solving we have some direction. Let's gather some information to help us figure out a solution.

    • Is the problem time related? Does it happen regularly or randomly.
    • Check your logs, all of them, not just the particular services's logs as something else may be causing the problem. Log entries generally have timestamps, this is to help you correlate events across multiple applications and services - use them. If necessary increase the log verbosity too.
    • Watch what your system is doing. Use tools like top, vmstat, iostat, sar, ps,tcpdump or even full blown monitoring systems.

  2. Analyse the information you have gathered. What is actually happening on the system when the service stops responding? What is the state of the system's resources ?

  3. Take appropriate action to remediate. Hopefully it's pretty obvious what's going on, you're running out of memory and OOM killer comes out to play, your swap activity is too high, your run queue is too long, you're iobound etc. If it's not obvious then you're probably not gathering the correct data - you know what to do, go back to 2.

  4. Monitor what the changes introduced at 4. do.

  5. Did the changes fix the problem ? Is it better? Is it worse ? Is there no difference ? Where you go from here depends on what you find. You may need to go back to 2. and gather more pertinent data or 3. to reanalyse what data you have or 4. because you identified a number of potential solutions.

  6. Document your findings and the changes you made.

  7. Go back to bed/home from work/to the pub.

user9517
  • 114,104
  • 20
  • 206
  • 289
  • Hi, thanks for your reply. I will check for system monitor tools. Meanwhile I have edit my question and pasted error.log and my.cnf. Please see if you can pointout something. – manish Aug 10 '15 at 10:27
  • 1
    @manish there is nothing useful in the logs or my.cnf. – user9517 Aug 10 '15 at 11:05
0

I agree with the above. Take a methodical approach to troubleshooting this, flapping wildly doesn't usually help.

It would seem like the SSH daemon is stopping so get onto the box with console access through your hosts control panel (If they don't provide console access, then move host) and restart the service. Now get going through the logs, monitor system performance with tools such as top or iotop and try to figure out what happens to the box right before SSH dies.

Its important you document any changes you made and what you ultimately did to fix it.

Tom

tomstephens89
  • 981
  • 1
  • 11
  • 23