Announcement

Announcement Module
Collapse
No announcement yet.

CentOS 5 and Percona Startup (and my.cnf feedback request)

Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Thanks! Here it is:

    [root@tigdb1 ~]# ausearch -ts 00:00:39 -sv no
    ----
    time->Wed Sep 7 00:01:11 2011
    type=SYSCALL msg=audit(1315368071.587:126877): arch=c000003e syscall=4 success=no exit=-13 a0=1a5e270 a1=7fff0c597930 a2=7fff0c597930 a3=8 items=0 ppid=10772 pid=10786 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=5510 comm="mysqld_safe" exe="/bin/bash" subj=unconfined_u:system_r:mysqld_safe_t:s0 key=(null)
    type=AVC msg=audit(1315368071.587:126877): avc: denied { read } for pid=10786 comm="mysqld_safe" name="mysql" dev=dm-0 ino=262357 scontext=unconfined_u:system_r:mysqld_safe_t:s0 tcontext=unconfined_ubject_r:var_lib_t:s0 tclass=lnk_file

    Comment


    • #17
      Do you have setroubleshoot installed? if yes - make sure setroubleshootd is started, repeat once more and look into /var/log/messages for messages about SELinux.
      Can still see "tclass=lnk_file" which means you have a symlink, probably /var/lib/mysql ->
      Please, list where your datadir resides, .sock and .pid files. What are the path-related values in my.cnf

      Comment


      • #18
        I just installed setroubleshoot but it doesn't log anything there, or to its own logs (/var/log/setroubleshoot/)

        I've removed the symlink /var/lib/mysql but I had changed all the paths.

        In my.cnf:

        [client]
        port = 3306
        socket = /var/run/mysqld/mysql.sock

        # The MySQL server
        [mysqld]
        datadir = /home/mysql
        port = 3306
        socket = /var/run/mysqld/mysql.sock
        pid-file = /var/run/mysqld/mysql.pid

        To clarify, now there is no audit error message either. But MySQL gives the same error when trying to start:

        [root@tigdb1 mysql]# /etc/init.d/mysql start
        Starting MySQL (Percona Server). ERROR! Manager of pid-file quit without updating file.

        Comment


        • #19
          Now try to launch mysqld from command line instead of init.d. Loot what it complains about

          Comment


          • #20
            Getting closer maybe

            The issue was it didn't want to start as root. So then I added user=mysql under [mysql]

            (however, /etc/init.d/mysql already had user=mysql)

            Now, when I do the service start it still gives the error

            But command line starting works...

            [root@tigdb1 ~]# /etc/init.d/mysql start
            Starting MySQL (Percona Server). ERROR! Manager of pid-file quit without updating file.

            [root@tigdb1 ~]# mysqld
            110908 1:58:03 [Note] Flashcache bypass: disabled
            110908 1:58:03 [Note] Flashcache setup error is : ioctl failed

            InnoDB: The InnoDB memory heap is disabled
            InnoDB: Mutexes and rw_locks use GCC atomic builtins
            InnoDB: Compressed tables use zlib 1.2.3
            110908 1:58:03 InnoDB: Initializing buffer pool, size = 16.0G
            110908 1:58:04 InnoDB: Completed initialization of buffer pool
            110908 1:58:04 InnoDB: highest supported file format is Barracuda.
            110908 1:58:05 Percona XtraDB (http://www.percona.com) 1.0.17-12.5 started; log sequence number 544093743541
            110908 1:58:05 [Note] Event Scheduler: Loaded 0 events
            110908 1:58:05 [Note] mysqld: ready for connections.
            Version: '5.1.58-rel12.9-log' socket: '/var/run/mysqld/mysql.sock' port: 3306 Percona Server (GPL), 12.9, Revision 271

            Comment


            • #21
              Attach your init script here. I'll compare with my

              Comment


              • #22
                Here it is. Thank you!

                Comment


                • #23
                  OK. Nothing specific in it.
                  Now run
                  ausearch -ts -sv no --raw > mysqld_selinux.log
                  sealert -a mysqld_selinux.log

                  Post output here.

                  Comment


                  • #24
                    I would disable SELinux.

                    Proof that it is more trouble than it's worth? A bunch of threads like this one. It's an epic hassle and it will rear its head again in the future, probably in some obscure way like during crash recovery, when you least need it.

                    Comment


                    • #25
                      I don't think disabling SELinux is good idea at all. You cal always add mysql_t to permissive domain at leat. In this case other daemons will be protected with SELinux.

                      BTW in CentOS 6 all works just out of the box. Consider upgrading

                      Comment


                      • #26
                        I meant to say CentOS 6 - that's what I'm using! (clarified in the second msg)

                        Going to get that new output ASAP.

                        Comment


                        • #27
                          no details.

                          [root@tigdb1 ~]# date
                          Sat Sep 10 19:47:52 EDT 2011
                          [root@tigdb1 ~]# /etc/init.d/mysql start
                          Starting MySQL (Percona Server). ERROR! Manager of pid-file quit without updating file.
                          [root@tigdb1 ~]# ausearch -ts 19:47 -sv no --raw > mysqld_sel.log
                          [root@tigdb1 ~]# sealert -a mysqld_sel.log
                          0% donefound 0 alerts in mysqld_sel.log

                          Comment


                          • #28
                            Hmm. That is strange. No messages in audit means that it is not SELinux causing problems.
                            Then try to issue
                            date
                            setenforce 0
                            service mysqld start
                            ausearch -ts

                            Comment


                            • #29
                              I have yet to hear a convincing argument that SELinux actually makes a MySQL database server more secure. If it does, you're probably doing something else very wrong. Like installing something other than just MySQL on the machine, or exposing the machine to the Internet.

                              By the way, SELinux also has a huge performance impact, which doesn't go away just by putting it into permissive mode. It has to be disabled completely.

                              Comment


                              • #30
                                I suppose you have tests and numbers?
                                Can I see performance comparison w/wo SELinux?

                                Comment

                                Working...
                                X