Server outrages - Page 49

gd_barnes · 2019-04-15, 02:33

Server and ports are back up. Sorry about the outage.

MooMoo2 · 2019-05-05, 22:58

There is something strange going on.

http://noprimeleftbehind.net/tps/ is up and running, but

http://noprimeleftbehind.net:12000/all.html is down, and I can't get any work from port 12000.

gd_barnes · 2019-05-06, 00:47

The server machine continues to reboot itself. It may be a day before I can get it fixed.

gd_barnes · 2019-05-06, 20:25

Bad power supply in server machine. Replaced. Everything looks good now.

gd_barnes · 2020-01-09, 23:53

The NPLB and CRUS PRPnet servers are down and have been for over 12 hours.

It is not a computer issue. The NPLB and CRUS web pages are OK and I am able to update them.

I am getting a MySQL error that I am unable to fix when I try to start a PRPnet server. It is:
Connect to database failed: [MySQL][ODBC 3.51 Driver]Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2), native code=2002

It is an old Linux machine.

I have tried stopping and restarting MySQL with:
sudo service mysql stop
sudo service mysql start

The stop works fine. When it tries to start it fails with:
* Starting MySQL database server mysqld [ OK ]
* Checking for corrupt, not cleanly closed and upgrade needing tables.
gary@jeepford:~$ ERROR 2013 (HY000) at line 2: Lost connection to MySQL server during query

I have shut down the machine and restarted several times. A few times the PRPnet servers would run for awhile and then shut down. Other times they would not run at all.

I would appreciate any help.

unconnected · 2020-01-10, 06:09

Gary, check mysqld log for errors, usually it is located at /var/log/mysqld.log. Also it make sense to check *.err files in the mysql data directory (/var/lib/mysql usually). Check that you have enough disk space and free ram.

If there are errors about db/tables corruption in logs, run the next command to check: 'mysqlcheck --all-databases --check --verbose'. This command only checks db structure/integrity, for fix use with --repair option (it is good idea to backup data directory first).
Hope this helps.

gd_barnes · 2020-01-10, 08:09

Dmitry,

Here is a screen shot of my recent attempt to do what you suggested:

Code:

gary@jeepford:~$ sudo service mysql status
[sudo] password for gary: 
 * MySQL is stopped.
gary@jeepford:~$ sudo service mysql start
 * Starting MySQL database server mysqld                                           [ OK ] 
 * Checking for corrupt, not cleanly closed and upgrade needing tables.
gary@jeepford:~$ ERROR 2013 (HY000) at line 2: Lost connection to MySQL server during query

gary@jeepford:~$ mysqlcheck --all-databases
mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connect
gary@jeepford:~$ mysqlcheck --all-databases --repair
mysqlcheck: Got error: 2002: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) when trying to connect
gary@jeepford:~$

As you can see I cannot execute the commands because I cannot connect. Any suggestions?

I'm ignorant about MySQL.

unconnected · 2020-01-10, 08:18

Ah, mysqlcheck command is useless if mysqld service is not even run. Gary, what you see in the log files?

gd_barnes · 2020-01-10, 08:39

Here are the last few pages. I hope this is enough.

Code:

Jan 10 02:34:22 jeepford mysqld[8351]: This could be because you hit a bug. It is also possible that this binary
Jan 10 02:34:22 jeepford mysqld[8351]: or one of the libraries it was linked against is corrupt, improperly built,
Jan 10 02:34:22 jeepford mysqld[8351]: or misconfigured. This error can also be caused by malfunctioning hardware.
Jan 10 02:34:22 jeepford mysqld[8351]: We will try our best to scrape up some info that will hopefully help diagnose
Jan 10 02:34:22 jeepford mysqld[8351]: the problem, but since we have already crashed, something is definitely wrong
Jan 10 02:34:22 jeepford mysqld[8351]: and this may fail.
Jan 10 02:34:22 jeepford mysqld[8351]:
Jan 10 02:34:22 jeepford mysqld[8351]: key_buffer_size=134217728
Jan 10 02:34:22 jeepford mysqld[8351]: read_buffer_size=6291456
Jan 10 02:34:22 jeepford mysqld[8351]: max_used_connections=0
Jan 10 02:34:22 jeepford mysqld[8351]: max_connections=200
Jan 10 02:34:22 jeepford mysqld[8351]: threads_connected=0
Jan 10 02:34:22 jeepford mysqld[8351]: It is possible that mysqld could use up to
Jan 10 02:34:22 jeepford mysqld[8351]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2588672 K
Jan 10 02:34:22 jeepford mysqld[8351]: bytes of memory
Jan 10 02:34:22 jeepford mysqld[8351]: Hope that's ok; if not, decrease some variables in the equation.
Jan 10 02:34:22 jeepford mysqld[8351]:
Jan 10 02:34:22 jeepford mysqld[8351]: thd=(nil)
Jan 10 02:34:22 jeepford mysqld[8351]: Attempting backtrace. You can use the following information to find out
Jan 10 02:34:22 jeepford mysqld[8351]: where mysqld died. If you see no messages after this, something went
Jan 10 02:34:22 jeepford mysqld[8351]: terribly wrong...
Jan 10 02:34:22 jeepford mysqld[8351]: frame pointer is NULL, did you compile with
Jan 10 02:34:22 jeepford mysqld[8351]: -fomit-frame-pointer? Aborting backtrace!
Jan 10 02:34:22 jeepford mysqld[8351]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
Jan 10 02:34:22 jeepford mysqld[8351]: information that should help you find out what is causing the crash.
Jan 10 02:34:22 jeepford mysqld_safe[8368]: Number of processes running now: 0
Jan 10 02:34:22 jeepford mysqld_safe[8370]: restarted
Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Log scan progressed past the checkpoint lsn 65 3180302167
Jan 10 02:34:22 jeepford mysqld[8373]: 200110  2:34:22  InnoDB: Database was not shut down normally!
Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Starting crash recovery.
Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Reading tablespace information from the .ibd files...
Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Restoring possible half-written data pages from the doublewrite
Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: buffer...
Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Doing recovery: scanned up to log sequence number 65 3185544704
Jan 10 02:34:22 jeepford mysqld[8373]: InnoDB: Doing recovery: scanned up to log sequence number 65 3186966404
Jan 10 02:34:22 jeepford mysqld[8373]: 200110  2:34:22  InnoDB: Starting an apply batch of log records to the database...
Jan 10 02:34:46 jeepford mysqld[8373]: InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
Jan 10 02:34:46 jeepford mysqld[8373]: InnoDB: Apply batch completed
Jan 10 02:34:46 jeepford mysqld[8373]: 200110  2:34:46  InnoDB: Started; log sequence number 65 3186966404
Jan 10 02:34:46 jeepford mysqld[8373]: 200110  2:34:46 [Note] /usr/sbin/mysqld: ready for connections.
Jan 10 02:34:46 jeepford mysqld[8373]: Version: '5.0.75-0ubuntu10.5'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: Error: trying to access page number 1768430057 in space 0,
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: space name ./ibdata1,
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: which is outside the tablespace bounds.
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: Byte offset 0, len 16384, i/o type 10.
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: If you get this error at mysqld startup, please check that
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: your my.cnf matches the ibdata files that you have in the
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: MySQL server.
Jan 10 02:34:47 jeepford mysqld[8373]: 200110  2:34:47InnoDB: Assertion failure in thread 140683719387472 in file fil0fil.c line 3959
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: We intentionally generate a memory trap.
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: If you get repeated assertion failures or crashes, even
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: immediately after the mysqld startup, there may be
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Jan 10 02:34:47 jeepford mysqld[8373]: InnoDB: about forcing recovery.
Jan 10 02:34:47 jeepford mysqld[8373]: 200110  2:34:47 - mysqld got signal 11 ;
Jan 10 02:34:47 jeepford mysqld[8373]: This could be because you hit a bug. It is also possible that this binary
Jan 10 02:34:47 jeepford mysqld[8373]: or one of the libraries it was linked against is corrupt, improperly built,
Jan 10 02:34:47 jeepford mysqld[8373]: or misconfigured. This error can also be caused by malfunctioning hardware.
Jan 10 02:34:47 jeepford mysqld[8373]: We will try our best to scrape up some info that will hopefully help diagnose
Jan 10 02:34:47 jeepford mysqld[8373]: the problem, but since we have already crashed, something is definitely wrong
Jan 10 02:34:47 jeepford mysqld[8373]: and this may fail.
Jan 10 02:34:47 jeepford mysqld[8373]:
Jan 10 02:34:47 jeepford mysqld[8373]: key_buffer_size=134217728
Jan 10 02:34:47 jeepford mysqld[8373]: read_buffer_size=6291456
Jan 10 02:34:47 jeepford mysqld[8373]: max_used_connections=0
Jan 10 02:34:47 jeepford mysqld[8373]: max_connections=200
Jan 10 02:34:47 jeepford mysqld[8373]: threads_connected=0
Jan 10 02:34:47 jeepford mysqld[8373]: It is possible that mysqld could use up to
Jan 10 02:34:47 jeepford mysqld[8373]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2588672 K
Jan 10 02:34:47 jeepford mysqld[8373]: bytes of memory
Jan 10 02:34:47 jeepford mysqld[8373]: Hope that's ok; if not, decrease some variables in the equation.
Jan 10 02:34:47 jeepford mysqld[8373]:
Jan 10 02:34:47 jeepford mysqld[8373]: thd=(nil)
Jan 10 02:34:47 jeepford mysqld[8373]: Attempting backtrace. You can use the following information to find out
Jan 10 02:34:47 jeepford mysqld[8373]: where mysqld died. If you see no messages after this, something went
Jan 10 02:34:47 jeepford mysqld[8373]: terribly wrong...
Jan 10 02:34:47 jeepford mysqld[8373]: frame pointer is NULL, did you compile with
Jan 10 02:34:47 jeepford mysqld[8373]: -fomit-frame-pointer? Aborting backtrace!
Jan 10 02:34:47 jeepford mysqld[8373]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
Jan 10 02:34:47 jeepford mysqld[8373]: information that should help you find out what is causing the crash.
Jan 10 02:34:48 jeepford mysqld_safe[8395]: Number of processes running now: 0
Jan 10 02:34:48 jeepford mysqld_safe[8397]: restarted
Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Log scan progressed past the checkpoint lsn 65 3180302167
Jan 10 02:34:48 jeepford mysqld[8400]: 200110  2:34:48  InnoDB: Database was not shut down normally!
Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Starting crash recovery.
Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Reading tablespace information from the .ibd files...
Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Restoring possible half-written data pages from the doublewrite
Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: buffer...
Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Doing recovery: scanned up to log sequence number 65 3185544704
Jan 10 02:34:48 jeepford mysqld[8400]: InnoDB: Doing recovery: scanned up to log sequence number 65 3186966404
Jan 10 02:34:48 jeepford mysqld[8400]: 200110  2:34:48  InnoDB: Starting an apply batch of log records to the database...
Jan 10 02:35:13 jeepford mysqld[8400]: InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
Jan 10 02:35:13 jeepford mysqld[8400]: InnoDB: Apply batch completed
Jan 10 02:35:13 jeepford mysqld[8400]: 200110  2:35:13  InnoDB: Started; log sequence number 65 3186966404
Jan 10 02:35:13 jeepford mysqld[8400]: 200110  2:35:13 [Note] /usr/sbin/mysqld: ready for connections.
Jan 10 02:35:13 jeepford mysqld[8400]: Version: '5.0.75-0ubuntu10.5'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: Error: trying to access page number 1768430057 in space 0,
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: space name ./ibdata1,
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: which is outside the tablespace bounds.
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: Byte offset 0, len 16384, i/o type 10.
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: If you get this error at mysqld startup, please check that
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: your my.cnf matches the ibdata files that you have in the
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: MySQL server.
Jan 10 02:35:14 jeepford mysqld[8400]: 200110  2:35:14InnoDB: Assertion failure in thread 140060547017040 in file fil0fil.c line 3959
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: We intentionally generate a memory trap.
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: If you get repeated assertion failures or crashes, even
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: immediately after the mysqld startup, there may be
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Jan 10 02:35:14 jeepford mysqld[8400]: InnoDB: about forcing recovery.
Jan 10 02:35:14 jeepford mysqld[8400]: 200110  2:35:14 - mysqld got signal 11 ;
Jan 10 02:35:14 jeepford mysqld[8400]: This could be because you hit a bug. It is also possible that this binary
Jan 10 02:35:14 jeepford mysqld[8400]: or one of the libraries it was linked against is corrupt, improperly built,
Jan 10 02:35:14 jeepford mysqld[8400]: or misconfigured. This error can also be caused by malfunctioning hardware.
Jan 10 02:35:14 jeepford mysqld[8400]: We will try our best to scrape up some info that will hopefully help diagnose
Jan 10 02:35:14 jeepford mysqld[8400]: the problem, but since we have already crashed, something is definitely wrong
Jan 10 02:35:14 jeepford mysqld[8400]: and this may fail.
Jan 10 02:35:14 jeepford mysqld[8400]:
Jan 10 02:35:14 jeepford mysqld[8400]: key_buffer_size=134217728
Jan 10 02:35:14 jeepford mysqld[8400]: read_buffer_size=6291456
Jan 10 02:35:14 jeepford mysqld[8400]: max_used_connections=0
Jan 10 02:35:14 jeepford mysqld[8400]: max_connections=200
Jan 10 02:35:14 jeepford mysqld[8400]: threads_connected=0
Jan 10 02:35:14 jeepford mysqld[8400]: It is possible that mysqld could use up to
Jan 10 02:35:14 jeepford mysqld[8400]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2588672 K
Jan 10 02:35:14 jeepford mysqld[8400]: bytes of memory
Jan 10 02:35:14 jeepford mysqld[8400]: Hope that's ok; if not, decrease some variables in the equation.
Jan 10 02:35:14 jeepford mysqld[8400]:
Jan 10 02:35:14 jeepford mysqld[8400]: thd=(nil)
Jan 10 02:35:14 jeepford mysqld[8400]: Attempting backtrace. You can use the following information to find out
Jan 10 02:35:14 jeepford mysqld[8400]: where mysqld died. If you see no messages after this, something went
Jan 10 02:35:14 jeepford mysqld[8400]: terribly wrong...
Jan 10 02:35:14 jeepford mysqld[8400]: frame pointer is NULL, did you compile with
Jan 10 02:35:14 jeepford mysqld[8400]: -fomit-frame-pointer? Aborting backtrace!
Jan 10 02:35:14 jeepford mysqld[8400]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
Jan 10 02:35:14 jeepford mysqld[8400]: information that should help you find out what is causing the crash.
Jan 10 02:35:14 jeepford mysqld_safe[8436]: Number of processes running now: 0
Jan 10 02:35:14 jeepford mysqld_safe[8438]: restarted
Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: Log scan progressed past the checkpoint lsn 65 3180302167
Jan 10 02:35:14 jeepford mysqld[8441]: 200110  2:35:14  InnoDB: Database was not shut down normally!
Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: Starting crash recovery.
Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: Reading tablespace information from the .ibd files...
Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: Restoring possible half-written data pages from the doublewrite
Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: buffer...
Jan 10 02:35:14 jeepford mysqld[8441]: InnoDB: Doing recovery: scanned up to log sequence number 65 3185544704
Jan 10 02:35:15 jeepford mysqld[8441]: InnoDB: Doing recovery: scanned up to log sequence number 65 3186966404
Jan 10 02:35:15 jeepford mysqld[8441]: 200110  2:35:15  InnoDB: Starting an apply batch of log records to the database...

gd_barnes · 2020-01-10, 08:45

Here are the first few pages after shutting machine down and turning it back on:

Code:

Jan 10 02:06:07 jeepford syslogd 1.5.0#5ubuntu3: restart.
Jan 10 02:06:07 jeepford anacron[3197]: Job `cron.daily' terminated (exit status: 1) (mailing output)
Jan 10 02:06:07 jeepford sendmail[4500]: 00A867GF004500: from=root, size=294, class=0, nrcpts=1, msgid=<202001100806.00A867GF004500@jeepford.no-ip.org>, relay=root@localhost
Jan 10 02:06:07 jeepford sm-mta[4501]: 00A867BR004501: from=<root@jeepford.no-ip.org>, size=570, class=0, nrcpts=1, msgid=<202001100806.00A867GF004500@jeepford.no-ip.org>, proto=ESMTP, daemon=MTA-v4, relay=jeepford.no-ip.org [127.0.0.1]
Jan 10 02:06:07 jeepford sendmail[4500]: 00A867GF004500: to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30294, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (00A867BR004501 Message accepted for delivery)
Jan 10 02:06:07 jeepford anacron[3197]: Normal exit (1 job run)
Jan 10 02:06:07 jeepford sm-mta[4502]: 00A867BR004501: to=<root@jeepford.no-ip.org>, ctladdr=<root@jeepford.no-ip.org> (0/0), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30804, dsn=2.0.0, stat=Sent
Jan 10 02:06:08 jeepford avahi-daemon[3078]: Invalid query packet.
Jan 10 02:06:17 jeepford avahi-daemon[3078]: Invalid query packet.
Jan 10 02:06:19 jeepford mysqld[4344]: InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
Jan 10 02:06:19 jeepford mysqld[4344]: InnoDB: Apply batch completed
Jan 10 02:06:19 jeepford mysqld[4344]: 200110  2:06:19  InnoDB: Started; log sequence number 65 3186966404
Jan 10 02:06:19 jeepford mysqld[4344]: 200110  2:06:19 [Note] /usr/sbin/mysqld: ready for connections.
Jan 10 02:06:19 jeepford mysqld[4344]: Version: '5.0.75-0ubuntu10.5'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: Error: trying to access page number 1768430057 in space 0,
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: space name ./ibdata1,
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: which is outside the tablespace bounds.
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: Byte offset 0, len 16384, i/o type 10.
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: If you get this error at mysqld startup, please check that
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: your my.cnf matches the ibdata files that you have in the
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: MySQL server.
Jan 10 02:06:20 jeepford mysqld[4344]: 200110  2:06:20InnoDB: Assertion failure in thread 140681679481168 in file fil0fil.c line 3959
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: We intentionally generate a memory trap.
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: If you get repeated assertion failures or crashes, even
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: immediately after the mysqld startup, there may be
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Jan 10 02:06:20 jeepford mysqld[4344]: InnoDB: about forcing recovery.
Jan 10 02:06:20 jeepford mysqld[4344]: 200110  2:06:20 - mysqld got signal 11 ;
Jan 10 02:06:20 jeepford mysqld[4344]: This could be because you hit a bug. It is also possible that this binary
Jan 10 02:06:20 jeepford mysqld[4344]: or one of the libraries it was linked against is corrupt, improperly built,
Jan 10 02:06:20 jeepford mysqld[4344]: or misconfigured. This error can also be caused by malfunctioning hardware.
Jan 10 02:06:20 jeepford mysqld[4344]: We will try our best to scrape up some info that will hopefully help diagnose
Jan 10 02:06:20 jeepford mysqld[4344]: the problem, but since we have already crashed, something is definitely wrong
Jan 10 02:06:20 jeepford mysqld[4344]: and this may fail.
Jan 10 02:06:20 jeepford mysqld[4344]:
Jan 10 02:06:20 jeepford mysqld[4344]: key_buffer_size=134217728
Jan 10 02:06:20 jeepford mysqld[4344]: read_buffer_size=6291456
Jan 10 02:06:20 jeepford mysqld[4344]: max_used_connections=0
Jan 10 02:06:20 jeepford mysqld[4344]: max_connections=200
Jan 10 02:06:20 jeepford mysqld[4344]: threads_connected=0
Jan 10 02:06:20 jeepford mysqld[4344]: It is possible that mysqld could use up to
Jan 10 02:06:20 jeepford mysqld[4344]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2588672 K
Jan 10 02:06:20 jeepford mysqld[4344]: bytes of memory
Jan 10 02:06:20 jeepford mysqld[4344]: Hope that's ok; if not, decrease some variables in the equation.
Jan 10 02:06:20 jeepford mysqld[4344]:
Jan 10 02:06:20 jeepford mysqld[4344]: thd=(nil)
Jan 10 02:06:20 jeepford mysqld[4344]: Attempting backtrace. You can use the following information to find out
Jan 10 02:06:20 jeepford mysqld[4344]: where mysqld died. If you see no messages after this, something went
Jan 10 02:06:20 jeepford mysqld[4344]: terribly wrong...
Jan 10 02:06:20 jeepford mysqld[4344]: frame pointer is NULL, did you compile with
Jan 10 02:06:20 jeepford mysqld[4344]: -fomit-frame-pointer? Aborting backtrace!
Jan 10 02:06:20 jeepford mysqld[4344]: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
Jan 10 02:06:20 jeepford mysqld[4344]: information that should help you find out what is causing the crash.
Jan 10 02:06:20 jeepford mysqld_safe[4515]: Number of processes running now: 0
Jan 10 02:06:20 jeepford mysqld_safe[4517]: restarted
Jan 10 02:06:20 jeepford mysqld[4520]: InnoDB: Log scan progressed past the checkpoint lsn 65 3180302167
Jan 10 02:06:20 jeepford mysqld[4520]: 200110  2:06:20  InnoDB: Database was not shut down normally!
Jan 10 02:06:20 jeepford mysqld[4520]: InnoDB: Starting crash recovery.
Jan 10 02:06:20 jeepford mysqld[4520]: InnoDB: Reading tablespace information from the .ibd files...
Jan 10 02:06:20 jeepford mysqld[4520]: InnoDB: Restoring possible half-written data pages from the doublewrite
Jan 10 02:06:20 jeepford mysqld[4520]: InnoDB: buffer...
Jan 10 02:06:21 jeepford mysqld[4520]: InnoDB: Doing recovery: scanned up to log sequence number 65 3185544704
Jan 10 02:06:21 jeepford mysqld[4520]: InnoDB: Doing recovery: scanned up to log sequence number 65 3186966404
Jan 10 02:06:21 jeepford mysqld[4520]: 200110  2:06:21  InnoDB: Starting an apply batch of log records to the database...
Jan 10 02:06:45 jeepford mysqld[4520]: InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
Jan 10 02:06:45 jeepford mysqld[4520]: InnoDB: Apply batch completed
Jan 10 02:06:45 jeepford mysqld[4520]: 200110  2:06:45  InnoDB: Started; log sequence number 65 3186966404
Jan 10 02:06:45 jeepford mysqld[4520]: 200110  2:06:45 [Note] /usr/sbin/mysqld: ready for connections.
Jan 10 02:06:45 jeepford mysqld[4520]: Version: '5.0.75-0ubuntu10.5'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: Error: trying to access page number 1768430057 in space 0,
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: space name ./ibdata1,
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: which is outside the tablespace bounds.
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: Byte offset 0, len 16384, i/o type 10.
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: If you get this error at mysqld startup, please check that
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: your my.cnf matches the ibdata files that you have in the
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: MySQL server.
Jan 10 02:06:46 jeepford mysqld[4520]: 200110  2:06:46InnoDB: Assertion failure in thread 139678118078800 in file fil0fil.c line 3959
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: We intentionally generate a memory trap.
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: If you get repeated assertion failures or crashes, even
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: immediately after the mysqld startup, there may be
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: corruption in the InnoDB tablespace. Please refer to
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
Jan 10 02:06:46 jeepford mysqld[4520]: InnoDB: about forcing recovery.
Jan 10 02:06:46 jeepford mysqld[4520]: 200110  2:06:46 - mysqld got signal 11 ;
Jan 10 02:06:46 jeepford mysqld[4520]: This could be because you hit a bug. It is also possible that this binary
Jan 10 02:06:46 jeepford mysqld[4520]: or one of the libraries it was linked against is corrupt, improperly built,
Jan 10 02:06:46 jeepford mysqld[4520]: or misconfigured. This error can also be caused by malfunctioning hardware.
Jan 10 02:06:46 jeepford mysqld[4520]: We will try our best to scrape up some info that will hopefully help diagnose
Jan 10 02:06:46 jeepford mysqld[4520]: the problem, but since we have already crashed, something is definitely wrong
Jan 10 02:06:46 jeepford mysqld[4520]: and this may fail.
Jan 10 02:06:46 jeepford mysqld[4520]:
Jan 10 02:06:46 jeepford mysqld[4520]: key_buffer_size=134217728
Jan 10 02:06:46 jeepford mysqld[4520]: read_buffer_size=6291456
Jan 10 02:06:46 jeepford mysqld[4520]: max_used_connections=0

rebirther · 2020-01-10, 09:54

try this here:
https://chepri.com/mysql-innodb-corr...-and-recovery/

2020-01-09, 23:53	#533
gd_barnes May 2007 Kansas; USA 11×937 Posts	The NPLB and CRUS PRPnet servers are down and have been for over 12 hours. It is not a computer issue. The NPLB and CRUS web pages are OK and I am able to update them. I am getting a MySQL error that I am unable to fix when I try to start a PRPnet server. It is: Connect to database failed: [MySQL][ODBC 3.51 Driver]Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2), native code=2002 It is an old Linux machine. I have tried stopping and restarting MySQL with: sudo service mysql stop sudo service mysql start The stop works fine. When it tries to start it fails with: * Starting MySQL database server mysqld [ OK ] * Checking for corrupt, not cleanly closed and upgrade needing tables. gary@jeepford:~$ ERROR 2013 (HY000) at line 2: Lost connection to MySQL server during query I have shut down the machine and restarted several times. A few times the PRPnet servers would run for awhile and then shut down. Other times they would not run at all. I would appreciate any help. Last fiddled with by gd_barnes on 2020-01-09 at 23:55

2020-01-10, 08:18	#536
unconnected May 2009 Russia, Moscow 100111101001₂ Posts	Ah, mysqlcheck command is useless if mysqld service is not even run. Gary, what you see in the log files? Last fiddled with by unconnected on 2020-01-10 at 08:18

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
What exactly is sent to the server?	paul0	NFS@Home	2	2015-03-12 23:00
Server bug -- new?	Christenson	Information & Answers	5	2011-07-12 21:44
Server Down?	Grant	Information & Answers	13	2008-11-24 19:37
New ECM-server available	andi314	Factoring	3	2003-08-31 11:22
New Server Hardware and price quotes, Funding the server	Angular	PrimeNet	32	2002-12-09 01:12

2019-04-15, 02:33	#529
gd_barnes May 2007 Kansas; USA 2843₁₆ Posts	Server and ports are back up. Sorry about the outage.

2019-05-05, 22:58	#530
MooMoo2 Aug 2010 1147₈ Posts	There is something strange going on. http://noprimeleftbehind.net/tps/ is up and running, but http://noprimeleftbehind.net:12000/all.html is down, and I can't get any work from port 12000.

2019-05-06, 00:47	#531
gd_barnes May 2007 Kansas; USA 11×937 Posts	The server machine continues to reboot itself. It may be a day before I can get it fixed.

2019-05-06, 20:25	#532
gd_barnes May 2007 Kansas; USA 11×937 Posts	Bad power supply in server machine. Replaced. Everything looks good now.

2020-01-10, 06:09	#534
unconnected May 2009 Russia, Moscow 43·59 Posts	Gary, check mysqld log for errors, usually it is located at /var/log/mysqld.log. Also it make sense to check *.err files in the mysql data directory (/var/lib/mysql usually). Check that you have enough disk space and free ram. If there are errors about db/tables corruption in logs, run the next command to check: 'mysqlcheck --all-databases --check --verbose'. This command only checks db structure/integrity, for fix use with --repair option (it is good idea to backup data directory first). Hope this helps.

2020-01-10, 09:54	#539
rebirther Sep 2011 Germany 2718₁₀ Posts	try this here: https://chepri.com/mysql-innodb-corr...-and-recovery/