Failed connect to 127.0.0.1:9500 after every reboot.

Comments

3 comments

  • Official comment
    Avatar
    Ashraf Sharif

    Hi,

    By default, cmon is installed with a cronjob to recover the service, it's located at /etc/cron.d/cmon. In case if MySQL is inaccessible, it keeps trying to connect to the MySQL server every minute right after that. Check /var/log/cmon.log and /var/log/cron for details.

    So the answer is, you don't have to wait for MariaDB to start first. As long as MySQL/MariaDB is going to be started, cmon will recover the service by itself.

    Regards,
    Ashraf

    Comment actions Permalink
  • Avatar
    Tenuun

    Not auto relaunching cmon. after first failure waiting for mariadb

    file exists under /etc/cron.d/cmon but it is completely empty! 

    Aug 27 11:00:01 ha1 crond[1047]: (*system*) RELOAD (/etc/cron.d/cmon)

    cmon log desn't say anything four days empty while 

    2019-08-23 07:05:28 : (INFO) License is enterprise version.
    2019-08-23 07:05:28 : (INFO) CmonCommandHandler started, polling for commands.
    2019-08-23 07:05:28 : (INFO) Aborting DEQUEUED, RUNNING and DEFINED jobs
    2019-08-27 02:59:23 : (INFO) Additional RPC URL for events: 'http://127.0.0.1:9510'
    2019-08-27 02:59:23 : (INFO) Configuration loaded.
    2019-08-27 02:59:23 : (INFO) Loaded configuration file '/etc/cmon.cnf'.
    2019-08-27 02:59:23 : (INFO) Initializing the user manager.
    2019-08-27 02:59:23 : (INFO) User manager is connecting the Cmon Database.
    2019-08-27 02:59:23 : (INFO) Checking that the system users exist.
    2019-08-27 02:59:23 : (INFO) Starting user manager thread.
    2019-08-27 02:59:23 : (INFO) Server started at tcp://127.0.0.1:9500
    2019-08-27 02:59:23 : (INFO) Server started at tls://127.0.0.1:9501
    2019-08-27 02:59:23 : (INFO) Initializing controller manager.
    2019-08-27 02:59:23 : (INFO) Cmon HA is disabled, running in single mode.
    2019-08-27 02:59:23 : (INFO) Checking command handler.
    2019-08-27 02:59:23 : (INFO) CDT entry '/.runtime/controller_clock' found.
    2019-08-27 02:59:23 : (INFO) Starting the command handler.
    2019-08-27 02:59:23 : (INFO) Loading configuration file '/etc/cmon.d/cmon_2.cnf'.
    2019-08-27 02:59:23 : (INFO) cmon 1.7.3.3374
    2019-08-27 02:59:23 : (INFO) CmonDb database is 'cmon' with schema version 107030.
    2019-08-27 02:59:23 : (INFO) Running cmon schema hot-fixes.
    2019-08-27 02:59:23 : (INFO) Applying modifications from 'cmon_db_mods_hotfix.sql'.
    2019-08-27 02:59:23 : (INFO) Loaded configuration file '/etc/cmon.d/cmon_2.cnf'.
    2019-08-27 02:59:23 : (INFO) Starting main loop.
    2019-08-27 02:59:23 : (INFO) Schema auto-upgrade succeed (version 107030).
    2019-08-27 02:59:23 : (INFO) Applying modifications from 'cmon_db_mods_hotfix.sql'.
    2019-08-27 02:59:23 : (INFO) Checked tables - everything is ok.
    2019-08-27 02:59:23 : (WARNING) Alarm raised: License expiration.
    2019-08-27 02:59:23 : (INFO) License is enterprise version.
    2019-08-27 02:59:23 : (INFO) CmonCommandHandler started, polling for commands.

    0
    Comment actions Permalink
  • Avatar
    Ashraf Sharif

    Hi,

    We found a bug in the cmon service to properly handle cmon process recovery in case the MySQL/MariaDB is not started. This has been fixed in the latest release clustercontrol-controller-1.7.3-3388. Details at https://severalnines.com/docs/changelog.html 

    Please upgrade to the latest version and try again. Upgrade instructions at https://severalnines.com/docs/administration.html#upgrading-clustercontrol 

    Regards,
    Ashraf

    0
    Comment actions Permalink

Please sign in to leave a comment.

Powered by Zendesk