mySQL abgeschmiert?

Post by **pg-computer** » 2003-03-27 20:43

Hoi Hoi,

was hat die Fehlermeldung zu bedeuten?

mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149fae
0x814edce
0x80d2180
0x80d0f46
0x80cf82d
0x80b6710
0x80b9948
0x80b5954
0x80b4e57
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8247540 = SELECT a.forum_id, a.auth_read, a.auth_mod
FROM inselkampf_forum_auth_access a,
inselkampf_forum_user_group ug
WHERE ug.user_id = 28
AND ug.user_pending = 0
AND a.group_id = ug.group_id

thd->thread_id = 80241
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 80241 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030327 19:11:55 mysqld restarted
/usr/sbin/mysqld: ready for connection

der hat zwar automatisch restart gemacht, aber würde mich trotzdem mal interessieren! ;)

Danke im Voraus!

Post by **pg-computer** » 2003-04-01 19:14

Hoi Hoi,

Beantwortung meiner Frage selbst: war irgendeine defekte Indexdatei bzw. Tabelle in einer Datenbank eines Kunden :-D

Nach Neuanlegen bzw. REPAIR gings wieder

Post by **kase** » 2003-04-01 20:04

Es könnte aber auch sein, dass deine Index Datei wegen dem Crash fehlerhaft war, dies also nur eine Folge des mysql Absturzes war, und das Problem doch wo ganz anders liegt.

Aber wenns nicht wieder vorkommt, dann sollte man es als Ausnahmefall abhacken ;)

Post by **pg-computer** » 2003-04-15 18:07

Hoi Hoi,

21 Tage war Ruhe und jetzt geht das schon wieder los, dass sich der mySQL Server mal neu gestartet... hmm komisch, werde das mal weiterbeobachten und ggf. die Logs mal hier posten!

Post by **pg-computer** » 2003-04-15 19:32

mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x80ce0f7
0x80cce00
0x80ca7df
0x80c9b2c
0x80caa25
0x80cac98
0x80b6696
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x823dbc8 = SELECT t.*, u.username, u.user_id, u2.username as user2, u2.user_id as id2, p.post_time, p.post_username
FROM phpbb_topics t, phpbb_users u, phpbb_posts p, phpbb_users u2
WHERE t.forum_id = 19
AND t.topic_poster = u.user_id
AND p.post_id = t.topic_last_post_id
AND p.poster_id = u2.user_id
AND t.topic_type = 2
ORDER BY t.topic_last_post_id DESC
thd->thread_id = 10
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 10 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030415 18:46:07 mysqld restarted
/usr/sbin/mysqld: ready for connections

hmm, was kann man dagegen tun?
mySQL Version: 3.23.37

Danke im Voraus!

PG-Computer

Post by **pg-computer** » 2003-04-29 20:02

Hoi Hoi,

brauche nochmal eure Hilfe..

Code: Select all

030415 19:32:17  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x80f3f2e
0x80da171
0x80d0879
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x823e060 = SELECT g.group_id, g.group_name 
        FROM phpbb_auth_access aa, phpbb_user_group ug, phpbb_groups g 
        WHERE aa.forum_id = 2
                AND aa.auth_mod = 1 
                AND g.group_single_user = 0
                AND g.group_type <> 2
                AND ug.group_id = aa.group_id 
                AND g.group_id = aa.group_id 
        GROUP BY g.group_id, g.group_name  
        ORDER BY g.group_id
thd->thread_id = 19
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 19 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030415 19:34:33  mysqld restarted
/usr/sbin/mysqld: ready for connections
030415 19:35:28  /usr/sbin/mysqld: Normal shutdown

030415 19:35:28  /usr/sbin/mysqld: Shutdown Complete

030415 19:35:28  mysqld ended

030415 19:35:29  mysqld started
/usr/sbin/mysqld: ready for connections
030415 19:41:45  /usr/sbin/mysqld: Normal shutdown

030415 19:41:45  /usr/sbin/mysqld: Shutdown Complete

030415 19:41:45  mysqld ended

030415 19:41:46  mysqld started
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x814a58a
0x80ee688
0x80d0a13
0x80d1469
0x80cf81d
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x82531a8 = SELECT aa.forum_id, u.user_id, u.username 
                FROM phpbb_auth_access aa, phpbb_user_group ug, phpbb_groups g, phpbb_users u
                WHERE aa.auth_mod = 1 
                        AND g.group_single_user = 1 
                        AND ug.group_id = aa.group_id 
                        AND g.group_id = aa.group_id 
                        AND u.user_id = ug.user_id 
                GROUP BY u.user_id, u.username, aa.forum_id 
                ORDER BY aa.forum_id, u.user_id
thd->thread_id = 7315
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 7315 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030418 01:54:30  mysqld restarted
/usr/sbin/mysqld: ready for connections
030418 12:30:19  /usr/sbin/mysqld: Normal shutdown

030418 12:30:19  /usr/sbin/mysqld: Shutdown Complete

030418 12:30:19  mysqld ended

030418 12:30:39  mysqld started
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x80ac250
0x80ac4ac
0x80c8832
0x80a9b5d
0x80d7cb3
0x80d08ac
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8291140 = SELECT u.*, s.*
                        FROM phpbb_sessions s, phpbb_users u
                        WHERE s.session_id = 'c284869a1d4a3eb6140136ed880861d5'
                                AND u.user_id = s.session_user_id
thd->thread_id = 23599
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 23599 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030425 18:49:42  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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...
Cannot determine thread, ebp=0xbfffefb4, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x80aba9b
0x80b1738
0x80b0ebb
0x40116c5f
0x8089af1
New value of ebp failed sanity check, terminating backtrace!

Number of processes running now: 0
030425 20:48:00  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x814a58a
0x809d782
0x80f21d2
0x80f1cfd
0x80eea6a
0x80e0b3d
0x80b7833
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x821f4d8 = UPDATE phpbb_users 
                                                        SET user_session_time = 1051310711, user_session_page = 11 
                                                        WHERE user_id = 17
thd->thread_id = 538
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 538 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030426 00:45:11  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x814a58a
0x809d782
0x80f21d2
0x80f1cfd
0x80eea6a
0x80e0b3d
0x80b7833
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8230ee0 = UPDATE phpbb_users 
                                                        SET user_session_time = 1051311950, user_session_page = 11 
                                                        WHERE user_id = 9
thd->thread_id = 55
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 55 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030426 01:05:50  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x80ac250
0x80ac4ac
0x80c8832
0x80a9b5d
0x80d7cb3
0x80d08ac
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x823c4e8 = SELECT u.*, s.*
                        FROM phpbb_sessions s, phpbb_users u
                        WHERE s.session_id = '9c8f63d2b1e16f5db56db00bc8922af1'
                                AND u.user_id = s.session_user_id
thd->thread_id = 106
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 106 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030426 01:40:48  mysqld restarted
/usr/sbin/mysqld: ready for connections
030426 21:03:46  Aborted connection 2854 to db: 'usr_web17_1' user: 'web17' host: `localhost' (Got an error reading communication packets)
030427 17:37:08  /usr/sbin/mysqld: Normal shutdown

030427 17:37:08  /usr/sbin/mysqld: Shutdown Complete

030427 17:37:08  mysqld ended

030427 17:37:08  mysqld started
/usr/sbin/mysqld: ready for connections
030428 16:45:24  Aborted connection 4460 to db: 'confixx' user: 'confixx' host: `localhost' (Got an error reading communication packets)
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x80ac250
0x80ac4ac
0x80c8832
0x80a9b5d
0x80d7cb3
0x80d08ac
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x822c348 = SELECT u.*, s.*
                        FROM phpbb_sessions s, phpbb_users u
                        WHERE s.session_id = 'b380ab9daf2dce223816edd0a5b1a87c'
                                AND u.user_id = s.session_user_id
thd->thread_id = 8597
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 8597 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030429 15:10:24  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x400b9609
0x400b97f0
0x80d6628
0x80cff22
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x82901c8 = SELECT c.cat_id, c.cat_title, c.cat_order
                FROM phpbb_categories c, phpbb_forums f
                WHERE f.cat_id = c.cat_id
                GROUP BY c.cat_id, c.cat_title, c.cat_order
                ORDER BY c.cat_order
thd->thread_id = 290
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 290 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030429 16:31:30  mysqld restarted
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x814a58a
0x809d782
0x80f21d2
0x80f1cfd
0x80eea6a
0x80d0a13
0x80d1469
0x80cf81d
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8253f58 = SELECT u.user_id, u.username 
        FROM phpbb_auth_access aa, phpbb_user_group ug, phpbb_groups g, phpbb_users u
        WHERE aa.forum_id = 2 
                AND aa.auth_mod = 1 
                AND g.group_single_user = 1
                AND ug.group_id = aa.group_id 
                AND g.group_id = aa.group_id 
                AND u.user_id = ug.user_id 
        GROUP BY u.user_id, u.username  
        ORDER BY u.user_id
thd->thread_id = 30
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 30 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030429 16:34:12  mysqld restarted
/usr/sbin/mysqld: ready for connections
030429 16:34:23  /usr/sbin/mysqld: Normal shutdown

030429 16:34:23  /usr/sbin/mysqld: Shutdown Complete

030429 16:34:23  mysqld ended

030429 16:34:37  mysqld started
/usr/sbin/mysqld: ready for connections
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x4020f950
0x8149f9e
0x814a58a
0x809d782
0x80f21d2
0x80f1cfd
0x80eea6a
0x80d0a13
0x80d1469
0x80cf81d
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8236420 = SELECT a.forum_id, a.auth_view, a.auth_mod 
                        FROM phpbb_auth_access a, phpbb_user_group ug 
                        WHERE ug.user_id = 2 
                                AND ug.user_pending = 0 
                                AND a.group_id = ug.group_id

thd->thread_id = 18
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 18 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030429 16:36:35  mysqld restarted
/usr/sbin/mysqld: ready for connections
030429 18:00:20  Aborted connection 419 to db: 'usr_web20_1' user: 'web20' host: `localhost' (Got an error reading communication packets)
030429 18:37:40  Aborted connection 502 to db: 'usr_web17_1' user: 'web17' host: `localhost' (Got an error reading communication packets)
mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died.
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 range sanity check OK, backtrace follows:
0x40085e9d
0x80ac250
0x80ac4ac
0x80c8832
0x80a9b5d
0x80d7cb3
0x80d08ac
0x80b6700
0x80b9938
0x80b5944
0x80b4e47
Stack trace successful, trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x82485e8 = SELECT u.*, s.*
                        FROM phpbb_sessions s, phpbb_users u
                        WHERE s.session_id = 'bfbfa07d257319a211f0796e1dd1d06e'
                                AND u.user_id = s.session_user_id
thd->thread_id = 729
Successfully dumped variables, if you ran with --log,
take a look at the details of what thread 729 did to cause the crash.
In some cases of really bad corruption, this value may be invalid
Please use the information above to create a repeatable
test case for the crash, and send it to bugs@lists.mysql.com

Number of processes running now: 0
030429 19:50:14  mysqld restarted
/usr/sbin/mysqld: ready for connections

meine my.cnf

Code: Select all

# Example mysql config file for medium systems.
#
# This is for a system with little memory (32M - 64M) where MySQL plays
# a important part and systems up to 128M very MySQL is used together with
# other programs (like a web server)
#
# You can copy this file to
# /etc/mf.cnf to set global options,
# mysql-data-dir/my.cnf to set server-specific options (in this
# installation this directory is /var/lib/mysql) or
# ~/.my.cnf to set user-specific options.
#
# One can in this file use all long options that the program supports.
# If you want to know which options a program support, run the program
# with --help option.

# The following options will be passed to all MySQL clients
[client]
#password       = your_password
port            = 3306
socket          = /var/lib/mysql/mysql.sock

# Here follows entries for some specific programs

# The MySQL server
[mysqld]
port            = 3306
socket          = /var/lib/mysql/mysql.sock
skip-locking
set-variable    = key_buffer=16M
set-variable    = max_allowed_packet=12M
set-variable    = table_cache=64
set-variable    = sort_buffer=512K
set-variable    = net_buffer_length=8K
set-variable    = myisam_sort_buffer_size=8M
log-bin
server-id       = 1
safe-show-database

# Point the following paths to different dedicated disks
#tmpdir         = /tmp/
#log-update     = /path-to-dedicated-directory/hostname

# Uncomment the following if you are using BDB tables
#set-variable   = bdb_cache_size=4M
#set-variable   = bdb_max_lock=10000

# Uncomment the following if you are using Innobase tables
#innodb_data_home_dir = /var/lib/mysql/
#innodb_log_group_home_dir = /var/lib/mysql/
#innodb_log_arch_dir = /var/lib/mysql/
#innodb_data_file_path = ibdata1:25M;ibdata2:37M;ibdata3:100M;ibdata4:300M
#set-variable = innodb_mirrored_log_groups=1
#set-variable = innodb_log_files_in_group=3
#set-variable = innodb_log_file_size=5M
#set-variable = innodb_log_buffer_size=8M
#innodb_flush_log_at_trx_commit=1
#innodb_log_archive=0
#set-variable = innodb_buffer_pool_size=16M
#set-variable = innodb_additional_mem_pool_size=2M
#set-variable = innodb_file_io_threads=4
#set-variable = innodb_lock_wait_timeout=50

[mysqldump]
quick
set-variable    = max_allowed_packet=12M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates


[isamchk]
set-variable    = key_buffer=20M
set-variable    = sort_buffer=20M
set-variable    = read_buffer=2M
set-variable    = write_buffer=2M

[myisamchk]
set-variable    = key_buffer=20M
set-variable    = sort_buffer=20M
set-variable    = read_buffer=2M
set-variable    = write_buffer=2M

[mysqlhotcopy]
interactive-timeout

[safe_mysqld]
err-log=/var/log/mysqld.log

Muss ich hier evtl. was optimieren? Server hat 256 MB RAM, mir siehts so aus als würde der SQL Server versuchen Speicher abzuschneiden und fliegt deshalb!?

Vielen Dank im Voraus!

Nachtrag: ich weiß, ist nicht grad optimal, aber die Fehlermeldungen sind eben oft verschieden! :(

Post by **captaincrunch** » 2003-04-29 22:13

Nur mal kurz als kleiner Tip am Rande : die code-Buttons, und das, was sie bewirken erhöhen die Lesbarkeit solch langer Beiträge ganz enorm, und auch Links auf (längere) Configfiles werden hier (in den allermeisten Fällen) gelesen ...

Post by **pg-computer** » 2003-04-30 18:27

Hoi Hoi,

es wurde heute ein neuer Kernel installiert, mal gucken ob das was hilft! :-D

Ich meld mich wieder..

Danke!

PG-Computer

Post by **pg-computer** » 2003-05-01 11:50

Moinsen,

naja einmal hat er sich wieder verabschiedet, das tritt aber verstärkt bei Foren auf...

Code: Select all

 myisamchk --silent --force */*.MYI
myisamchk: MyISAM file confixx/allgemein.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file confixx/register.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file confixx/zeiten.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_forums.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_posts.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_posts_text.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_sessions.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_topics.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_topics_watch.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web17_1/phpbb_users.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_forums.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_posts.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_posts_text.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_search_wordlist.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_search_wordmatch.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: error: Key in wrong position at page 78848
myisamchk: MyISAM file usr_web20_1/phpbb_sessions.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_topics.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_users.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_vote_results.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly
myisamchk: MyISAM file usr_web20_1/phpbb_vote_voters.MYI
myisamchk: warning: 1 clients is using or hasn't closed the table properly

Kann das auch zu Abstürzen führen, laut mysql.de Dokumentation schon.. aber wieso treten solche Fehler erst auf? Sollte ich mal ein REPAIR auf diese Tabellen anwenden?

Danke im Voraus!

PG-Computer

Post by **jtb** » 2003-05-01 12:33

sicher, dass nicht gerade einer auf deinem Forum war, während du myisamcheck aufgerufen hast?

Post by **pg-computer** » 2003-05-01 12:45

Hi Jens,

nein hatte den mySQL Server runtergefahren, ich such ja immer noch die Ursache, wieso der abschmiert, es ist komisch, das fast nur die Sache bei phpBB2 Queries passiert, hab jetzt mal ein REPAIR per SQL über die Tabellen gejagt, scheint wieder alles zu passen, nur mal gucken wie der SQL Server sich macht, ob der immer wieder restartet...

Post by **mark** » 2003-05-01 12:47

Welche mysql-version setzt du eigentlich ein ?

3.23.56 ? 4.0.12 ?

Eventuell kannst du updaten ?

Gruß
Mark

Post by **jtb** » 2003-05-01 12:52

falls es wirklich am RAM oder CPU liegen sollte, würde ich mal ein Belastungstest machen..
Einmal direkt am mysql (mehre Queries gleichzeitig losjagen) und einmal das System selber.. Ein Kernel-Build ist bekannt dafür RAM-Probleme aufzudecken

btw: warum hast du log-bin an?

Post by **pg-computer** » 2003-05-01 12:55

Moin Moin,

mySQL Version 3.23.37...
das komische ist aber auch, dass andere Prozesse wie Apache, usw. keine Probleme machen, ein RAM Check wurde schon von den Admins gemacht und verlief ohne Probleme...
Log-bin war schon an im SuSE-RPM.. sind die RPMs von SuSE 7.2.

Wie könnte ich den mal so einen Test durchführen? ;) :-D

Post by **jtb** » 2003-05-01 12:55

mark wrote:Welche mysql-version setzt du eigentlich ein ?

3.23.56 ? 4.0.12 ?

Eventuell kannst du updaten ?

war doch mySQL Version: 3.23.37

Aber ein Update könnte man mal in Erwägung ziehen..
Zwischendurch wurde einiges gefixt.

Post by **jtb** » 2003-05-01 12:57

PG-Computer wrote: Wie könnte ich den mal so einen Test durchführen? ;) :-D

je nach Programmiersprache entweder threaded oder halt als einzelne Prozesse..

Die schnellste Lösung wäre jetzt die fehlgeschlagenen Queries aus den Debug-Reports zu nehmen und immer wieder nacheinander aufzurufen.. Die PHP-Datei kannst du dann beliebig oft starten und somit flexibel Last erzeugen..

Post by **pg-computer** » 2003-05-01 20:34

Hoi Hoi,

der verabschiedet sich immer wieder mal...
naja ist keine Sache!

Kann ich die RPMs hier aus dem Forum nehmen?
Ist SuSE 7.2 drauf.. DB Verzeichnis ist /var/lib/mysql

Klappt das dann alles?
Soweit ich das in Erinnerung hab kann man ja auch das Datadir fest eincompilieren, vielleicht ist das ja wirklich ein Bug in der mySQL Version!

Gruß

Peter

Post by **jtb** » 2003-05-01 20:44

warum updatest du nicht einfach mit YAST?

Post by **pg-computer** » 2003-05-01 22:50

hoi hoi,

dachte SuSE hat nur die Version 3.23.37... für Version 7.2 und immer nur die Update Packages... die patchen doch immer die Fehler raus..
Hab Yast noch nie groß benutzt, wenn ich die Security List angucke, die Versionen bleiben ja gleich, wie PHP, Sendmail usw. nur die Sicherheitslücken werden rausgepatcht, aber ne neue Version wirds in dem Sinne nicht :?:

Wie soll ich denn da vorgehen?

:?:

PG-Computer

Post by **dea** » 2003-05-01 22:53

Würd' ich mal rtfm machen ;) Schau mal unter http://server.1und1.com

Wenn ich mich nicht täusche gibt es auch in yast eine Option/Menüpunkt an dem man sein System "automatisch", d.h. über den SuSE-Server, aktualisieren kann.
Also diese Option einfach auswählen, noch mal genau prüfen, welche Pakete aktualisiert werden sollen und dann fire & forget ;)

Post by **pg-computer** » 2003-05-01 23:04

hoi hoi,

unter System updaten werden zwar Pakete angezeigt die ersetzt werden würden, aber da steht nichts von mySQL Server, die Update Quelle ist der SuSE Update Server für Version 7.2!

Post by **pg-computer** » 2003-05-03 23:53

Hoi Hoi,

hab jetzt die Sache mal geupdatet auf Version 3.23.54, mal schauen, was passiert, unter anderem kam aber auch schon wieder solcher Quatsch an root, das kommt nur ganz ganz selten mal, 1x am Tag, beim Rest läuft der Script, der hier den Fehler verursacht perfekt, entweder liegts am neuen Kernel oder isses doch ein tiefgründiges Hardwareproblem

Message 1:
From root Sat May 3 22:45:00 2003
Date: Sat, 3 May 2003 22:45:00 +0200
From: root@server1.pg-tw-server.de (Cron Daemon)
To: root@server1.pg-tw-server.de
Subject: Cron <root@server1> test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin>
X-Cron-Env: <MAILTO=root>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <LOGNAME=root>

find: error while loading shared libraries: libc.so.6: cannot load shared object file: Error 9

Naja was solls, mal abwarten ob mysqld wieder fliegt nach Update.

Danke erstmal!

Post by **pg-computer** » 2003-05-04 00:40

Moin,

so nach Update siehts folgendermaßen aus :-D

Code: Select all

/usr/sbin/mysqld: ready for connections
mysqld got signal 4;
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=16773120
record_buffer=131072
sort_buffer=524280
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to 
key_buffer_size + (record_buffer + sort_buffer)*max_connections = 80379 K
bytes of memory
Hope that's ok, if not, decrease some variables in the equation

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 range sanity check OK, backtrace follows:
0x80a87c5
0x40031e9d
0xbf9ff350
0x80b221e
0x80ae0fa
0x80ad577
Stack trace seems successful - bottom reached
Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x81f36a0 = SHOW TABLE STATUS LIKE 'phpbb_disallow'
thd->thread_id=526

Successfully dumped variables, if you ran with --log, take a look at the
details of what thread 526 did to cause the crash.  In some cases of really
bad corruption, the values shown above may be invalid

The manual page at http://www.mysql.com/doc/C/r/Crashing.html contains
information that should help you find out what is causing the crash

Number of processes running now: 0
030504 00:25:28  mysqld restarted
/usr/sbin/mysqld: ready for connections

Wird wohl doch die Hardware oder was weiß der Geier sein.... achja so ist das, wenn man nicht an den Rechner persönlich kann

Gruß und Danke

PG

Post by **pg-computer** » 2003-05-05 15:50

Hoi Hoi,

so das Problem scheint gefunden zu sein... eine defekte HDD!!!

Code: Select all

server1:~ # badblocks -v -s /dev/hda
Checking for bad blocks in read-only mode
From block 0 to 40209120
Checking for bad blocks (read-only test): 156128080/ 40209120
1561281
1561282
1561283
1561284
1561285
1561286
1561287
1561288
1561289
1561290
1561291
1561292
1561293
1561294
1561295
1561296
1561297
1561298
1561299
156130000/ 40209120
1561301
1561302
1561303
156130404/ 40209120
156130505/ 40209120
156130606/ 40209120
156130707/ 40209120

Danke aber trotzdem für euere Hilfe! :)
Wieder was gelernt!

Gruß

Peter

Post by **kase** » 2003-05-05 17:29

vielleicht für den ein oder anderen ganz hilfreich, thx, dass du die Lösung gepostest hast.

RootForum Community

mySQL abgeschmiert?

mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?

Re: mySQL abgeschmiert?