Bug #56192 unattended svc mgr update installer no longer starts dashboard at end
Submitted: 23 Aug 2010 15:03 Modified: 9 Sep 2010 14:33
Reporter: Carsten Segieth Email Updates:
Status: Closed Impact on me:
Category:MySQL Enterprise Monitor: Installing Severity:S3 (Non-critical)
Version: OS:Any
Assigned to: BitRock Merlin CPU Architecture:Any
Tags: regression

[23 Aug 2010 15:03] Carsten Segieth
Service manager update installer no longer starts the bundled mysqld and the tomcat at the end of the update install.

Build did start the dashboard 'as expected' at the end, so the change happened with the last changes for (which also uses the new IB version):

MySQL Enterprise Monitor Update --- Built on 2010-08-12 21:45:39 IB: 6.4.0-201007130840
MySQL Enterprise Monitor Update --- Built on 2010-08-19 23:45:11 IB: 6.5.2-201008191008

Tested with unattended install.

How to repeat:
- install, do the first-time update
- update to (see that the dashboard is 'active')
- update to (see that both mysqld and tomcat are not started)

The same happens with a direct update -->, so it is not a problem of updating 2.2.3 to 2.2.3.
[23 Aug 2010 16:07] Enterprise Tools JIRA Robot
Marcos Palacios writes: 
I ran a svc mgr upgrade install from to via the UI on Mac OS X and the dashboard started OK.

Will test on Windows via the UI next.
[23 Aug 2010 17:13] BitRock Merlin

We can not reproduce this error on Linux on our side. Could you put the same installers in the FTP server? Please run the upgrade installer with the --debugtrace filename.txt option and send us the file. Thanks.
[23 Aug 2010 19:27] Enterprise Tools JIRA Robot
Bill Weber writes: 
was only able to reproduce this using unattended (see attached debugtrace.txt) - it worked using attended and unattended
[24 Aug 2010 14:40] BitRock Merlin

The problem is that the servers are not started at the end of the upgrade from some versions in unattended mode.

We checked the installers that you sent us (mysqlmonitor- and mysqlmonitor- and we noticed that the servers do not start at the end of the upgrade in unattended mode.

The problem is that the cnf-comparer.jar tool finds some differences between the previous and the new my.cnf files. You can check the differences in the <installdir>/mysql/my.cnf_comparison_report.txt file. If the upgrade installer notices any difference in the my.cnf files, the installer will not start the servers automatically. There is an option in the final page to the user can choose if the services should be started even though differences were found between the actual and recommended cnf files. You can check #36528 bug for more information.

On unattended mode the final page is not shown so the servers are not started automatically. Our understanding is that the user should check the comparison report before start the servers. Please let us know if we should modify this approach.


[24 Aug 2010 15:42] Andy Bang
Just for reference, the my.cnf/my.ini change is a result of the fix for Bug #56004.
[24 Aug 2010 16:51] Enterprise Tools JIRA Robot
Andy Bang writes: 
Please add a similar option to unattended mode so the user can override the default and have the installer start the services even though a change in the cnf/ini file has been detected. The default should be as it is now (do not start the services if a change is detected), but there should be a way to override that even in unattended mode.
[25 Aug 2010 8:28] BitRock Merlin
Patch sent to Andy.

The new option is "forceRestart" to start the servers at the end of the installation even though a change in the cnf/ini file.
[9 Sep 2010 12:06] Enterprise Tools JIRA Robot
Carsten Segieth writes: 
tested OK in
- when there is a change of the my.cnf / my.ini and from this in unattended install the svc mgr is not started at the end as expected, one can use the new option '--forceRestart'. But, then the old, unchanged my.ini is used.
[9 Sep 2010 14:33] MC Brown
A note has been added to the 2.2.3 changelog: 

        When performing an unattended installation, the                                                                                  
        &merlin_server; would not be restarted automatically if the                                                                      
        configuration file contained changes. You can now force the                                                                      
        restart to occur by using                                                                                                        
        the <literal>--forceRestart</literal> option. When set to 1,                                                                     
        the server will be restarted using the old (unmodified)                                                                          
        configuration file.