MySQL Bugs: #56192: unattended svc mgr update installer no longer starts dashboard at end

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:	None
Category:	MySQL Enterprise Monitor: Installing	Severity:	S3 (Non-critical)
Version:	2.2.3.1741	OS:	Any
Assigned to:	BitRock Merlin	CPU Architecture:	Any
Tags:	regression

Description:
Service manager update installer no longer starts the bundled mysqld and the tomcat at the end of the update install.

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

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

Tested with unattended install.

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

The same happens with a direct update 2.2.0.1709 --> 2.2.3.1741, so it is not a problem of updating 2.2.3 to 2.2.3.

Marcos Palacios writes: 
I ran a svc mgr upgrade install from 2.1.1.1141 to 2.2.3.1741 via the UI on Mac OS X and the dashboard started OK.

Will test on Windows via the UI next.

Hi,

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.

Bill Weber writes: 
was only able to reproduce this using unattended 2.2.3.1741 (see attached debugtrace.txt) - it worked using 2.2.3.1751 attended and 2.2.3.1738 unattended

Hi,

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-2.2.0.1709-linux-x86_64-installer.bin and mysqlmonitor-2.2.3.1741-linux-x86_64-update-installer.bin) 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.

Regards,

Beltran

Just for reference, the my.cnf/my.ini change is a result of the fix for Bug #56004.

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.

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.

Carsten Segieth writes: 
tested OK in 2.2.3.1745:
- 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.

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.