MYSQL: Job failed to start

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

Hi Antonio,

Sounds like something happened (maybe a power surge or bad hardware?)
on your machine that caused mysql to get corrupted. Unfortunately,
there are no easy solutions.

Reboot your computer and the VM and if that doesn't help, you'll have
to try to recover the mysql data using the Linux command line. I
strongly recommend you make a copy of the VM before you attempt any
recovery.

If the data is important to recover safely and urgently, you should
probably get professional help. Most IT shops will be able to help and
the team at Nafundi is glad to assist if you fill out the form at
http://nafundi.com/contact.

Yaw

··· -- Need ODK services? http://nafundi.com provides form design, server setup, professional support, and software development for ODK.

On Tue, Aug 11, 2015 at 6:31 AM, 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

--

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.

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

I think you've probably exceeded the knowledge of those of us using MySQL.

We generally just set it up to run with the default configuration, and
forget about it (except for periodic backups of the database for disaster
recovery).

··· On Tue, Aug 11, 2015 at 7:44 AM, 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

--

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.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

Hi

As Yaw mentioned you have database corruption. Try adding

innodb_force_recovery = 4

into my.cnf

Then follow the rest of the steps here

http://chepri.com/mysql-innodb-corruption-and-recovery/

Regards

··· On Tue, Aug 11, 2015 at 2:01 PM, Mitch Sundt wrote:

I think you've probably exceeded the knowledge of those of us using MySQL.

We generally just set it up to run with the default configuration, and
forget about it (except for periodic backups of the database for disaster
recovery).

On Tue, Aug 11, 2015 at 7:44 AM, 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

--

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.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--

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.

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

Antonio,

That was probably the cause of the corruption. There are lots of ways
to get data out of Aggregate without accessing it at the DB level.
https://opendatakit.org/use/aggregate/data-transfer/ has your options.
I don't know about your use case, but I find pulling the data via
Briefcase's CLI is the easiest.

Yaw

··· -- Need ODK services? http://nafundi.com provides form design, server setup, professional support, and software development for ODK.

On Wed, Aug 12, 2015 at 10:26 AM, Antonio Junior antonioj@itech-mozambique.org wrote:

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.