Hi Guys thanks for your attention
I added the line:
innodb_force_recovery = 4
And tried to restart mysql with no sucess even after multiples times
restarting the VM and services with the command "init 6".
I decided to reinstall and import the last backup.
I have some questions, could be useful in the future for me, they could be
out of the post also sorry if they are foolish questions.
Could this have been caused by accessing the ODK database from another
application, located on the same server and using a connector/jar different
from the one located on $CATALINA_HOME/lib?
I ask it because of this log entry, from the day the problem started,
according with log:
===============================LOG==================================
150806 6:25:02 [Warning] Using unique option prefix myisam-recover instead
of myisam-recover-options is deprecated and will be removed in a future
release. Please use the full name instead.
150806 6:25:02 [Note] Plugin 'FEDERATED' is disabled.
150806 6:25:02 InnoDB: The InnoDB memory heap is disabled
150806 6:25:02 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150806 6:25:02 InnoDB: Compressed tables use zlib 1.2.3.4
150806 6:25:03 InnoDB: Initializing buffer pool, size = 128.0M
150806 6:25:03 InnoDB: Completed initialization of buffer pool
InnoDB: Unable to lock ./ibdata1, error: 11
InnoDB: Check that you do not already have another mysqld process
InnoDB: using the same InnoDB data or log files.
150806 6:25:03 InnoDB: Retrying to lock the first data file
InnoDB: Unable to lock ./ibdata1, error: 11
===============================LOG==================================
How can I implement the pull action of the ODKbriefcase, so that I don't
have to access directly the ODK database, is there any implementation from
where I can get the idea?
Thank you!!
On Tue, Aug 11, 2015 at 4:44 PM, Antonio Junior antonioj@itech-mozambique.org wrote:
I added the following lines to the file my.cnf
innodb_use_sys_malloc = 0
federated
======================my.cnf================
innodb_use_sys_malloc = 0
[mysqld]
* Basic Settings
user = mysql
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
federated
The log now says:
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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb72523f3]
/usr/sbin/mysqld(handle_fatal_signal+0x484)[0xb70fe1e4]
[0xb6db0400]
/usr/sbin/mysqld(+0x52ef15)[0xb7301f15]
/usr/sbin/mysqld(+0x603bb9)[0xb73d6bb9]
/usr/sbin/mysqld(+0x5f980e)[0xb73cc80e]
/usr/sbin/mysqld(+0x5311d1)[0xb73041d1]
/usr/sbin/mysqld(+0x520a2e)[0xb72f3a2e]
/usr/sbin/mysqld(+0x525321)[0xb72f8321]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb6d35d4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb6b448be]
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.
150811 16:13:57 [Warning] Using unique option prefix myisam-recover
instead of myisam-recover-options is deprecated and will be removed in a
future release. Please use the full name instead.
150811 16:13:57 InnoDB: The InnoDB memory heap is disabled
150811 16:13:57 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150811 16:13:57 InnoDB: Compressed tables use zlib 1.2.3.4
150811 16:13:57 InnoDB: Initializing buffer pool, size = 128.0M
150811 16:13:57 InnoDB: Completed initialization of buffer pool
150811 16:13:57 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!
150811 16:13:57 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...
150811 16:13:57 InnoDB: Waiting for the background threads to start
150811 16:13:58 InnoDB: 5.5.40 started; log sequence number 4588262
150811 16:13:58 [Note] Server hostname (bind-address): '127.0.0.1'; port:
3306
150811 16:13:58 [Note] - '127.0.0.1' resolves to '127.0.0.1';
150811 16:13:58 [Note] Server socket created on IP: '127.0.0.1'.
150811 16:13:58 [Note] Event Scheduler: Loaded 0 events
150811 16:13:58 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.40-0ubuntu0.12.04.1' socket: '/var/run/mysqld/mysqld.sock'
port: 3306 (Ubuntu)
150811 16:13:58 InnoDB: Assertion failure in thread 2758204224 in file
trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
16:13:58 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=16777216
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 =
346075 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb72b73f3]
/usr/sbin/mysqld(handle_fatal_signal+0x484)[0xb71631e4]
[0xb6e15400]
/usr/sbin/mysqld(+0x52ef15)[0xb7366f15]
/usr/sbin/mysqld(+0x603bb9)[0xb743bbb9]
/usr/sbin/mysqld(+0x5f980e)[0xb743180e]
/usr/sbin/mysqld(+0x5311d1)[0xb73691d1]
/usr/sbin/mysqld(+0x520a2e)[0xb7358a2e]
/usr/sbin/mysqld(+0x525321)[0xb735d321]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb6d9ad4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb6ba98be]
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.
On Tue, Aug 11, 2015 at 1:31 PM, Antonio Junior antonioj@itech-mozambique.org wrote:
Hi all,
I am running ODK Aggregate VM 1.4.5.0 on my local server, and today I
realized that the application has stopped, when I try to browser it I
receive an Error 404.
The Apache Tomcat is running without problems, but MySQL has stopped,
this could be the root of the problem. I don't know why the service stopped,
trying to start it with "service mysql start" command returns Job failed to
start.
The log:
150811 12:40:13 [Warning] Using unique option prefix myisam-recover
instead of myisam-recover-options is deprecated and will be removed in a
future release. Please use the full name instead.
150811 12:40:13 [Note] Plugin 'FEDERATED' is disabled.
150811 12:40:13 InnoDB: The InnoDB memory heap is disabled
150811 12:40:13 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150811 12:40:13 InnoDB: Compressed tables use zlib 1.2.3.4
150811 12:40:13 InnoDB: Initializing buffer pool, size = 128.0M
150811 12:40:13 InnoDB: Completed initialization of buffer pool
150811 12:40:13 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!
150811 12:40:13 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...
150811 12:40:13 InnoDB: Waiting for the background threads to start
150811 12:40:14 InnoDB: 5.5.40 started; log sequence number 4588262
150811 12:40:14 [Note] Server hostname (bind-address): '127.0.0.1'; port:
3306
150811 12:40:14 [Note] - '127.0.0.1' resolves to '127.0.0.1';
150811 12:40:14 [Note] Server socket created on IP: '127.0.0.1'.
150811 12:40:14 [Note] Event Scheduler: Loaded 0 events
150811 12:40:14 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.40-0ubuntu0.12.04.1' socket: '/var/run/mysqld/mysqld.sock'
port: 3306 (Ubuntu)
150811 12:40:14 InnoDB: Assertion failure in thread 2758204224 in file
trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:40:14 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=16777216
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 =
346075 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 0x30000
/usr/sbin/mysqld(my_print_stacktrace+0x33)[0xb72eb3f3]
/usr/sbin/mysqld(handle_fatal_signal+0x484)[0xb71971e4]
[0xb6e49400]
/usr/sbin/mysqld(+0x52ef15)[0xb739af15]
/usr/sbin/mysqld(+0x603bb9)[0xb746fbb9]
/usr/sbin/mysqld(+0x5f980e)[0xb746580e]
/usr/sbin/mysqld(+0x5311d1)[0xb739d1d1]
/usr/sbin/mysqld(+0x520a2e)[0xb738ca2e]
/usr/sbin/mysqld(+0x525321)[0xb7391321]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d4c)[0xb6dced4c]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0xb6bdd8be]
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.
150811 12:40:15 [Warning] Using unique option prefix myisam-recover
instead of myisam-recover-options is deprecated and will be removed in a
future release. Please use the full name instead.
150811 12:40:15 [Note] Plugin 'FEDERATED' is disabled.
150811 12:40:15 InnoDB: The InnoDB memory heap is disabled
150811 12:40:15 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150811 12:40:15 InnoDB: Compressed tables use zlib 1.2.3.4
150811 12:40:15 InnoDB: Initializing buffer pool, size = 128.0M
150811 12:40:15 InnoDB: Completed initialization of buffer pool
150811 12:40:15 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!
150811 12:40:15 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...
150811 12:40:15 InnoDB: Waiting for the background threads to start
150811 12:40:16 InnoDB: 5.5.40 started; log sequence number 4588262
150811 12:40:16 [Note] Server hostname (bind-address): '127.0.0.1'; port:
3306
150811 12:40:16 [Note] - '127.0.0.1' resolves to '127.0.0.1';
150811 12:40:16 [Note] Server socket created on IP: '127.0.0.1'.
150811 12:40:16 [Note] Event Scheduler: Loaded 0 events
150811 12:40:16 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.40-0ubuntu0.12.04.1' socket: '/var/run/mysqld/mysqld.sock'
port: 3306 (Ubuntu)
150811 12:40:16 InnoDB: Assertion failure in thread 2758204224 in file
trx0purge.c line 840
InnoDB: Failing assertion: purge_sys->purge_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.5/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
12:40:16 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=16777216
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 =
346075 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Can any one help me.
--
António Paunde
Distance Education Specialist
Extension: 124
--
António Paunde
Distance Education Specialist
Extension: 124
--
António Paunde
Distance Education Specialist
Extension: 124
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.