New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Switch it off at the wall, turn it back on again.
Check your error logs?
Hire a system administrator, I would guess this is relating to changes you made from the other thread you had ( http://lowendtalk.com/discussion/34049/whm-is-not-upgrading-now#latest )
tail: cannot open `/var/log/mysql.err' for reading: No such file or directory
The log file is
/var/lib/mysql/<hostname>.err
this.
This is error file.
140908 11:04:01 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2014-09-08 11:04:01 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2014-09-08 11:04:01 26954 [Note] Plugin 'FEDERATED' is disabled.
2014-09-08 11:04:01 26954 [Note] InnoDB: Using atomics to ref count buffer pool pages
2014-09-08 11:04:01 26954 [Note] InnoDB: The InnoDB memory heap is disabled
2014-09-08 11:04:01 26954 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2014-09-08 11:04:01 26954 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-09-08 11:04:01 26954 [Note] InnoDB: Using Linux native AIO
2014-09-08 11:04:01 26954 [Note] InnoDB: Using CPU crc32 instructions
2014-09-08 11:04:01 26954 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2014-09-08 11:04:01 26954 [Note] InnoDB: Completed initialization of buffer pool
2014-09-08 11:04:01 26954 [Note] InnoDB: Highest supported file format is Barracuda.
2014-09-08 11:04:01 26954 [Note] InnoDB: Log scan progressed past the checkpoint lsn 6923856396
2014-09-08 11:04:01 26954 [Note] InnoDB: Database was not shutdown normally!
2014-09-08 11:04:01 26954 [Note] InnoDB: Starting crash recovery.
2014-09-08 11:04:01 26954 [Note] InnoDB: Reading tablespace information from the .ibd files...
2014-09-08 11:04:02 26954 [Note] InnoDB: Restoring possible half-written data pages
2014-09-08 11:04:02 26954 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 6923861060
2014-09-08 11:04:02 26954 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
2014-09-08 11:04:02 26954 [Note] InnoDB: 128 rollback segment(s) are active.
2014-09-08 11:04:02 26954 [Note] InnoDB: Waiting for purge to start
2014-09-08 11:04:02 7f2beb5fe700 InnoDB: Assertion failure in thread 139826609252096 in file trx0purge.cc line 699
InnoDB: Failing assertion: purge_sys->iter.trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
15:04:02 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68245 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8c8af5]
/usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x65ffb4]
/lib64/libpthread.so.0(+0xf710)[0x7f2c2285a710]
/lib64/libc.so.6(gsignal+0x35)[0x7f2c21505635]
/lib64/libc.so.6(abort+0x175)[0x7f2c21506e15]
/usr/sbin/mysqld[0xa25d16]
/usr/sbin/mysqld[0xa268c4]
/usr/sbin/mysqld[0xa27206]
/usr/sbin/mysqld[0xa17f8a]
/lib64/libpthread.so.0(+0x79d1)[0x7f2c228529d1]
/lib64/libc.so.6(clone+0x6d)[0x7f2c215bb86d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
140908 11:04:02 mysqld_safe mysqld from pid file /var/lib/mysql/fastest.csofts.net.pid ended
140908 11:05:14 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2014-09-08 11:05:15 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2014-09-08 11:05:15 1379 [Note] Plugin 'FEDERATED' is disabled.
2014-09-08 11:05:15 1379 [Note] InnoDB: Using atomics to ref count buffer pool pages
2014-09-08 11:05:15 1379 [Note] InnoDB: The InnoDB memory heap is disabled
2014-09-08 11:05:15 1379 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2014-09-08 11:05:15 1379 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-09-08 11:05:15 1379 [Note] InnoDB: Using Linux native AIO
2014-09-08 11:05:15 1379 [Note] InnoDB: Using CPU crc32 instructions
2014-09-08 11:05:15 1379 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2014-09-08 11:05:15 1379 [Note] InnoDB: Completed initialization of buffer pool
2014-09-08 11:05:15 1379 [Note] InnoDB: Highest supported file format is Barracuda.
2014-09-08 11:05:15 1379 [Note] InnoDB: Log scan progressed past the checkpoint lsn 6923856396
2014-09-08 11:05:15 1379 [Note] InnoDB: Database was not shutdown normally!
2014-09-08 11:05:15 1379 [Note] InnoDB: Starting crash recovery.
2014-09-08 11:05:15 1379 [Note] InnoDB: Reading tablespace information from the .ibd files...
2014-09-08 11:05:15 1379 [Note] InnoDB: Restoring possible half-written data pages
2014-09-08 11:05:15 1379 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 6923861070
2014-09-08 11:05:15 1379 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
2014-09-08 11:05:15 1379 [Note] InnoDB: 128 rollback segment(s) are active.
2014-09-08 11:05:15 1379 [Note] InnoDB: Waiting for purge to start
2014-09-08 11:05:15 7f8e235fe700 InnoDB: Assertion failure in thread 140248455571200 in file trx0purge.cc line 699
InnoDB: Failing assertion: purge_sys->iter.trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
15:05:15 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68245 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8c8af5]
/usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x65ffb4]
/lib64/libpthread.so.0(+0xf710)[0x7f8e59ec9710]
/lib64/libc.so.6(gsignal+0x35)[0x7f8e58b74635]
/lib64/libc.so.6(abort+0x175)[0x7f8e58b75e15]
/usr/sbin/mysqld[0xa25d16]
/usr/sbin/mysqld[0xa268c4]
/usr/sbin/mysqld[0xa27206]
/usr/sbin/mysqld[0xa17f8a]
/lib64/libpthread.so.0(+0x79d1)[0x7f8e59ec19d1]
/lib64/libc.so.6(clone+0x6d)[0x7f8e58c2a86d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
140908 11:05:15 mysqld_safe mysqld from pid file /var/lib/mysql/fastest.csofts.net.pid ended
140908 11:10:41 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
2014-09-08 11:10:42 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2014-09-08 11:10:42 9339 [Note] Plugin 'FEDERATED' is disabled.
2014-09-08 11:10:42 9339 [Note] InnoDB: Using atomics to ref count buffer pool pages
2014-09-08 11:10:42 9339 [Note] InnoDB: The InnoDB memory heap is disabled
2014-09-08 11:10:42 9339 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2014-09-08 11:10:42 9339 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-09-08 11:10:42 9339 [Note] InnoDB: Using Linux native AIO
2014-09-08 11:10:42 9339 [Note] InnoDB: Using CPU crc32 instructions
2014-09-08 11:10:42 9339 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2014-09-08 11:10:42 9339 [Note] InnoDB: Completed initialization of buffer pool
2014-09-08 11:10:42 9339 [Note] InnoDB: Highest supported file format is Barracuda.
2014-09-08 11:10:42 9339 [Note] InnoDB: Log scan progressed past the checkpoint lsn 6923856396
2014-09-08 11:10:42 9339 [Note] InnoDB: Database was not shutdown normally!
2014-09-08 11:10:42 9339 [Note] InnoDB: Starting crash recovery.
2014-09-08 11:10:42 9339 [Note] InnoDB: Reading tablespace information from the .ibd files...
2014-09-08 11:10:42 9339 [Note] InnoDB: Restoring possible half-written data pages
2014-09-08 11:10:42 9339 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 6923861080
2014-09-08 11:10:42 9339 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
2014-09-08 11:10:42 9339 [Note] InnoDB: 128 rollback segment(s) are active.
2014-09-08 11:10:42 9339 [Note] InnoDB: Waiting for purge to start
2014-09-08 11:10:42 7f7883fff700 InnoDB: Assertion failure in thread 140155587393280 in file trx0purge.cc line 699
InnoDB: Failing assertion: purge_sys->iter.trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
15:10:42 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68245 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x40000
/usr/sbin/mysqld(my_print_stacktrace+0x35)[0x8c8af5]
/usr/sbin/mysqld(handle_fatal_signal+0x4a4)[0x65ffb4]
/lib64/libpthread.so.0(+0xf710)[0x7f78bb18c710]
/lib64/libc.so.6(gsignal+0x35)[0x7f78b9e37635]
/lib64/libc.so.6(abort+0x175)[0x7f78b9e38e15]
/usr/sbin/mysqld[0xa25d16]
/usr/sbin/mysqld[0xa268c4]
/usr/sbin/mysqld[0xa27206]
/usr/sbin/mysqld[0xa17f8a]
/lib64/libpthread.so.0(+0x79d1)[0x7f78bb1849d1]
/lib64/libc.so.6(clone+0x6d)[0x7f78b9eed86d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
140908 11:10:42 mysqld_safe mysqld from pid file /var/lib/mysql/fastest.csofts.net.pid ended
Tell me what should i do now?
Hire a sys admin
+1.
@csofts If you have not been able to read through this log which you pasted here and understand the possible causes, then you need an admin to look after this issue.
Use pastebin.
afraid to ask, but... how exactly did you "upgrade" your mysql-version? (regarding to the other thread)
via apt, yum or whatever system this might be or... copying some binaries from here to there?
I suppose you didn't compile anything by yourself, don't you?
Run the update again.
Read the logs from the update.
Find the error, repair, restart
Dude, pastebin?
Pastebin or pre tag would be appreciated.
Try re-install, if not then hire a sysadmin.
didn't read through the clusterfuck of error log....Is your MySQL disk/partion full?
Could be that one or more Innodb databases are corrupt because of a dirty shutdown.
Theres an option to force recovery (possible data loss) when starting mysqld.
Now i again using 11.40 WHm version .Mysql is not upgrading.
You may want to consider hiring someone to fix this for you if you lack the ability to do so.
What distribution is that on?
You have an answer in your message.
Hire someone to fix it for you, LET is not a support desk.
Also if your cPanel licence is valid you may be better off asking them for help than here.
His website says Live Support 24/7 Hours 365 Days
Hello,
I have 4 years + epxerience in development . I have already asked from Cpanel Sysadmin. this said to me you can't upgrade this.here is wrong something else.you need to rebuilt this server. now i have rebuilt new server and move all backup to new server. This website is for Help and Share Problem each other.
Thanks
Regards
Junaid
Yes i hired on odesk.com but Sysadmin said to me that something is wrong else there.we can't upgrade this. so you need to rebuilt new server. now every thing ok i have rebuilt this and move backup and upgrade everything.
Development != SysAdmin
I have +/- 1 / 1.5 years of experience with Linux, but wouldnt trust myself running a (shared)production environment, let alone with little to no Linux experience
You are right but i know very well about sysadmin. i have resolved this issue myself.
You know, cPanel has their own support team, And they most likely would know how to fix it...
Sure you do. So why is it you posted here again?
In a timely fashion of course.