Skip to main content

Failed to validate my.cnf file for version 5.6

Kent Brockman
Hello guys! I'm interested in upgrading and old server to MariaDB 10.1 but the starting point is MySQL 5.5. When trying to upgrade to 5.6, this warning comes up:
System Specific Warnings Severity: Critical Message: The system detected issues with the current "/etc/my.cnf" file. These issues may interfere with the upgrade to MySQL 5.6: Failed to validate my.cnf file for version 5.6: 160830 2:58:27 [ERROR] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root! 160830 2:58:27 [ERROR] Aborting
What does this mean? The my.cnf does contain nothing weird. In fact is the same configuration as in other servers where it worked just fine. Even if I rename my.cnf to something else, the error is the same. And I didn't found anything like this by googling. Any ideas? Thanks in advance

Comments

13 comments

Date Votes
  • vacancy
    What's in the my.cnf file content?
    0
  • Kent Brockman
    Even if I emptied the my.cnf file the message is the same. So, I need some MySQL expert from cPanel here.
    0
  • Infopro
    Did you restart MySQL after renaming the file? Silly question I know. You don't mention it though so I thought I would. :)
    0
  • rpvw
    MySQL / MariaDB reads the my.cnf configuration files in a preset order. See the SQL docs for full details As well as an /etc/my.cnf, I found a /usr/my.cnf file that is read after the /etc/my.cnf You might want to search for any additional my.cnf files your system has :) perhaps your issue lies there.
    0
  • Kent Brockman
    @Infopro: nope! Since this message happens at prerequisites checkpoint, I didn't thought a restart would be necessary. I can test that of course, but late in the night, because this server have huge sites in production actually.
    0
  • Kent Brockman
    @rpvw: Please read my originally quoted code, it states that the conflict originate on "/etc/my.cnf". Just for the curious, this is the content of my /etc/my.cnf:
    [myisamchk] ft_min_word_len=2 key_buffer_size=64M sort_buffer_size=64M read_buffer=2M write_buffer=2M [mysqld] bind-address=127.0.0.1 tmp_table_size=120M max_heap_table_size=120M sort_buffer_size=6M read_buffer_size=2M read_rnd_buffer_size=2M default-storage-engine=INNODB query_cache_type=1 query_cache_size=128M query_cache_limit=1M ft_min_word_len=2 key_buffer_size=64M long_query_time=5 max_allowed_packet=268435456 max_connections=200 myisam_sort_buffer_size=8M net_buffer_length=16K open_files_limit=50000 table_cache=6000 table_definition_cache=6000 table_open_cache=6000 thread_cache_size=16 innodb_file_per_table=1 innodb_buffer_pool_size=61865984 [mysqldump] max_allowed_packet=16M quick [mysqlhotcopy] interactive-timeout
    Anything you can criticize? Let me know please.
    0
  • cPanelMichael
    Hi @Kent Brockman, The specific reason for the failed validation should appear in /usr/local/cpanel/logs/error_log when this happens. Do you notice any additional output in this log that's not in the UI? Thanks.
    0
  • Kent Brockman
    @cPanelMichael: The response obtained is the same that is logged in the file. Some images will clarify that: 40421 40431
    0
  • cPanelMichael
    Please post the output from the following command:
    mysql --version
    Thank you.
    0
  • Kent Brockman
    mysql --version


    # mysql --version mysql Ver 14.14 Distrib 5.5.35, for Linux (x86_64) using readline 5.1
    0
  • cPanelMichael
    The only time I've seen this happen in the past is when a third-party installation of Percona was installed, but that doesn't look to be the case here. Would you mind opening a support ticket so we can take a closer look? You can post the ticket number here so we can update this thread with the outcome. Thank you.
    0
  • Kent Brockman
    The only time I've seen this happen in the past is when a third-party installation of Percona was installed, but that doesn't look to be the case here. Would you mind opening a support ticket so we can take a closer look? You can post the ticket number here so we can update this thread with the outcome. Thank you.

    You're almost there pal. Yes, this is a VPS which originally came with Percona and I asked the hosting provider to switch it back to native MySQL. It was almost 2 years ago. Maybe some Percona debris may remain? And if so, will the tech ops in a ticket be able to cleanse it? I cannot move the sites hosted right now and at the same time wanted to at least upgrade to MySQL 5.6 to improve performance (the target of the switch is arrive to MariaDB 10 and PHP 7)
    0
  • cPanelMichael
    It's possible some leftover configuration data from the Percona installation is causing this problems. We can help to determine if that's the case in the support ticket, yes. Thank you.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post