Closed GoogleCodeExporter closed 9 years ago
That means that the syslogs_index_1 table is corrupted, which is often because
of a full disk. Can you verify that you are not out of space?
To repair the table, execute:
mysql -uroot -e "REPAIR TABLE syslog_data.syslogs_index_1"
Original comment by mchol...@gmail.com
on 10 Jul 2013 at 9:48
Thanks for the prompt reply.
Here is the disk usage and mysql command output.
[root@elsa-dev ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_elsadev-lv_root
16G 2.6G 13G 18% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/sda1 485M 73M 387M 16% /boot
[root@elsa-dev ~]# mysql -uroot -e "REPAIR TABLE
syslog_data.syslogs_index_1"
+-----------------------------+--------+----------+-----------------------------
---------+
| Table | Op | Msg_type | Msg_text
|
+-----------------------------+--------+----------+-----------------------------
---------+
| syslog_data.syslogs_index_1 | repair | Error | Table 'syslogs_index_1'
is read only |
| syslog_data.syslogs_index_1 | repair | error | Corrupt
|
+-----------------------------+--------+----------+-----------------------------
---------+
[root@elsa-dev ~]#
If I check all the tables in the syslog_data database, there is another
that appears to be corrupt.
[root@elsa-dev ~]# mysqlcheck -c syslog_data -u root
syslog_data.syslogs_archive_1
Error : Table 'syslogs_archive_1' is read only
error : Corrupt
syslog_data.syslogs_index_1
Error : Table 'syslogs_index_1' is read only
error : Corrupt
[root@elsa-dev ~]#
I receive the same output when attempting to repair the archive table.
On Wed, Jul 10, 2013 at 5:49 PM, <
enterprise-log-search-and-archive@googlecode.com> wrote:
Original comment by jsn.l...@gmail.com
on 11 Jul 2013 at 12:20
That's too bad, it sounds like you'll have to drop the table. If you can live
without the logs, try to issue a drop table command on syslogs_index_1 and
syslogs_archive_1, then restart syslog-ng.
Original comment by mchol...@gmail.com
on 12 Jul 2013 at 9:28
Hi,
I came across the same error on a fresh install using the install.sh script
from trunk (on CentOS 6.4 minimal).
There is no need to drop and recreate the tables, this is a selinux issue with
the linked tables in /data/elsa/mysql/
It can be fixed with: chcon --reference=/var/lib/mysql/test -R
"/data/elsa/mysql"
or disabling selinux of course.
[root@elsa-test mysql]# getenforce
Enforcing
[root@elsa-test mysql]# mysql -uroot -e "REPAIR TABLE
syslog_data.syslogs_index_1"
+-----------------------------+--------+----------+-----------------------------
--------------------------------------+
| Table | Op | Msg_type | Msg_text
|
+-----------------------------+--------+----------+-----------------------------
--------------------------------------+
| syslog_data.syslogs_index_1 | repair | error | Can't create new tempfile:
'/data/elsa/mysql/syslogs_index_1.TMD' |
| syslog_data.syslogs_index_1 | repair | status | Operation failed
|
+-----------------------------+--------+----------+-----------------------------
--------------------------------------+
[root@elsa-test mysql]# chcon --reference=/var/lib/mysql/test -R
"/data/elsa/mysql"
[root@elsa-test mysql]# mysql -uroot -e "REPAIR TABLE
syslog_data.syslogs_index_1"
+-----------------------------+--------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+-----------------------------+--------+----------+----------+
| syslog_data.syslogs_index_1 | repair | status | OK |
+-----------------------------+--------+----------+----------+
[root@elsa-test mysql]#
I am attaching a snippet from audit.log (grep for mysql avc denied)
type=AVC msg=audit(1375508351.304:616): avc: denied { write } for pid=1547
comm="mysqld" path="/data/elsa/mysql/syslogs_index_1.MYI" dev=dm-1 ino=1969676
scontext=unconfined_u:system_r:mysqld_t:s0
tcontext=system_u:object_r:httpd_log_t:s0 tclass=file
type=AVC msg=audit(1375508377.813:617): avc: denied { read } for pid=1553
comm="mysqld" path="/data/elsa/mysql/syslogs_archive_1.MYD" dev=dm-1
ino=1969698 scontext=unconfined_u:system_r:mysqld_t:s0
tcontext=system_u:object_r:httpd_log_t:s0 tclass=file
It seems that set_node_mysql function didn't run on install for some reason, or
it was not able to chcon.
Original comment by Just4N...@gmail.com
on 3 Aug 2013 at 7:47
Attachments:
Thanks!
If the database and schema already exist, it will bail out of set_node_mysql,
which might be why the chcon command got missed.
Original comment by mchol...@gmail.com
on 13 Aug 2013 at 11:07
Just wanted to thank Just4N and confirm that the issue exists with CentOS 4.x
minimal and selinux. The proposed fix works.
Original comment by lib...@gmail.com
on 18 Aug 2013 at 1:02
I ran into the same issue with CentOS 6.6 after I enabled SELINUX. chcon
--reference=/var/lib/mysql/test -R "/data/elsa/mysql" fixed my issues. Thanks.
Original comment by stevetu...@gmail.com
on 13 Mar 2015 at 4:37
Original issue reported on code.google.com by
jsn.l...@gmail.com
on 9 Jul 2013 at 7:44