MySQL Bugs: #27332: Installing 2+ Agents silently renames Windows Service, making Agent startup fail

Bug #27332	Installing 2+ Agents silently renames Windows Service, making Agent startup fail
Submitted:	21 Mar 2007 14:19	Modified:	27 May 2010 13:32
Reporter:	Johan Idrén	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Monitor: Installing	Severity:	S3 (Non-critical)
Version:	1.1.0.4973	OS:	Windows (Windows)
Assigned to:	BitRock Merlin	CPU Architecture:	Any

Description:
Installing a second (or third...) Agent on Windows, Windows silently renames the Service MySQLNetworkServiceAgent-n where n is installed Agents minus 1.

This makes Agent startup fail, since it assumes that Service installation was successful using the name MySQLNetworkServiceAgent.

How to repeat:
Install 2 or more Agents on Windows, second one fails to start.

Suggested fix:
If possible, check return of Service creation, taking the installed servicename, placing it in agentctl.bat to ensure startup.

Patch sent to Keith.

The bug was related to the installation process. We were creating a dynamic name for the agent windows service, but we were not updating agentctl.bat accordingly, as you've pointed out.

Corrections in versions => 1.1.0.4973

installing 3 agents with 1.1.0.4973 failed:

- the new installed service could be started by the installer, but the renaming looks funny in the Windows service manager:

 MySQL Network Service Agent
 MySQL Network Service Agent-1
 MySQL Network Service Agent-1-2
 MySQL Network Service Agent-1-2-3

- only the last one of the installs is visible in 
  * Start Menu 
  * RegDB under HKLM/Software
  * Add/Remove Programs Menu

So there is no link to uninstall all (n-1) old installations, only directly starting the uninstall.exe can help.

With the mysqld-nt.exe binary, there is a way to manually specify the service name to install a new service, such as:

C:\> "C:\Program Files\MySQL\MySQL Server 5.1\bin\mysqld" --install SecondMySQLInstance
This should be fixed in two stages probably:
1) The installer should not silently overwrite the existing services, it should fail and point them at the manual --install option
2) We should implement a service installation with --install within the agent binary for Windows

This is related to Bug #47475.

We can change the behavior of the agent installer to do the following if a previous installation is found

a) A warning, but allow the user to continue anyways

b) An error an exit the installer

Just let us know what you prefer.

Also, if people create their own services by hand, then they are expected to know how to upgrade them by hand as well (so as not to make the logic in the installer more fragile/complex to deal with multi-services scenarios, since you already decided the right place to do that is not the installer)

Gary Whizin writes: 
Here's what we suggest:
* add new commandline option to specify a new "service name" (e.g. --servicename=xxxxx)
** always record servicename in some persistent file that will be used by uninstall and update installers (today it's in agentctl.bat, for example)
* install should never silently rename a service; instead if you detect the presence of the name you were going to use, give a warning and abort. The warning tells them how to use the new --servicename option and gives an example they can cut/paste/edit
** we might be interested in this last scenario not aborting the installer but instead prompting for a new name; depends how hard/risky it is for you (let us know)

Yes, the installer needs to create a different shortcut (so the user can determine one agent from another when starting/stopping agents), as well as a different Add/Remove Programs entry (so the user can determine one agent from another when uninstalling).

In a nutshell, use whatever they enter for --servicename.

It seems like the current "Product Name" is "MySQL Enterprise Monitor Agent", and that is used as the registry name, shortcut, ARP entry, and installdir, and is also used as the service name with the spaces removed.

So, per the comment above at 6 Oct 21:05, if a user starts the installer without specifying --servicename, it defaults to "MySQL Enterprise Monitor Agent" and behaves as it does now.  However, if it determines that there's another installation with that default name, it stops and gives a message like this to the user:

  Error: The name "MySQL Enterprise Monitor Agent" is already in use.
         Each installation of the agent must have a unique name.
         Please either uninstall the existing instance, or start the
         installer with the --servicename flag to specify a new name
         for this instance.  For example:
         
         ./mysql-monitor-agent --servicename="MySQL Enterprise Monitor Agent 2"

Patch sent to Keith.

Keith Russell writes: 
Patch installed in versions => 2.2.0.1537.

Hi Carsten,

Our understanding is that patch should be only applied to 2.2.x versions. Could you confirm this?

Carsten Segieth writes: 
yes, you're right. My fault - I noticed this QAT together with a new Windows agent build ... and did not check the versions. Sorry.

Attachment: 10244_Windows service installer.jpg (image/jpeg, text), 110.70 KiB.

Patch sent to Keith. Per Andy request, we also implemented the same approach for Unix platforms.

Keith Russell writes: 
Patch installed in versions => 2.2.0.1611.

Carsten Segieth writes: 
starting with version 2.2.0.1611 both the entry in the Add-/Remove Programs Menu and in the Startmenu no longer has the blanks in that where specified on the command line.

For installs up to build 1606 it looked like "MySQL Enterprise Monitor Agent - 2.2.0.1606", now it looks  "MySQLEnterpriseMonitorAgent-2.2.0.1611".

More tests on the UI will follow, the above happened with unattended install.

Hi Carsten,

If the user has write permissions on "/", the installer is considering that it is the root user. As workaround please remove the write permissions for the "mysqldev" on the "/" for your testing. We will also fix this issue on InstallBuilder.

Patch sent to Keith.

Keith Russell writes: 
Patch pushed to installer repository.

Keith Russell writes: 
Patch installed in versions => 2.2.0.1616

Carsten Segieth writes: 
The 'fresh' install now looks ok, but the update installer breaks existing installations (Win service + Start- + ARP menu)

Using the agent update installer can result in a broken installation. It deletes an existing service entry, cannot create the new one ("already exists") but then starts the existing with the "default" name.

How to repeat:
- have an install "A" with "default" service / Start Menu name "MySQL Enterprise Monitor Agent"
- have another install "B" with "special" service / Start Menu name, e.g. "MySQL Enterprise Monitor Agent - 2.2.0.1620"
- start 2.2.0.1627 agent update install, choose the install dir of "B"
- see message box "Error creating service MySQLEnterpriseMonitorAgent"
- agentctl.bat in "B" now is changed to service name of "A"
- Win service of "B" is deleted, service entry "A" now connected with updated binaries "B"
- in StartMenu the entry of "A" now points to the updated binaries of "B"
- the 'old' Start Menu of "B" still exists and is still correct
- in the ARP menu now a new / renamed entry exists that points to uninstall "B"

Can it be that the update installer does not check whether the installation that is updated uses a different naming than the default?

Also, the new --servicename param is allowed (and used) in the update installer but not mentioned in the HELP message.

In case of an update it does change the service name and creates a new
start menu entry while leaving the old start menu entry one unchanged,
so it is 'somewhat' implemented, but not fully correct.

If the name is changed (e.g. to change to use the new version string) the objcts with the old name should be deleted.

Using the option is possible only from command line, the UI update installer does not show the "servicename" entry field. If it is added there it should show the servicename that was used by the installation specified by the installation directory which the user enters.

Patch sent to Keith. The Agent Upgrade will ignore the "--servicename" option and it will use the same service name that the previous installation.

Andy Bang writes: 
Patch received from BitRock.

Andy Bang writes: 
Included in build 2.2.0.1651

Carsten Segieth writes: 
Sorry, but there is still a problem after updating one of 2 installs:

- have install "A" with "default" service / Start Menu name "MySQL Enterprise Monitor Agent" (I installed 2.1.0.1093_GA)
- have install "B" with "special" service / Start Menu name, e.g. "MySQL Enterprise Monitor Agent - 2.2.0.1635"
- start 2.2.0.1652 agent update install, choose the install dir of "B"

Now, after the update of "B", we only have the Start Menu entries of "B" (which are correct), but the Start Menu of "A" does not exist anymore (no folder, no links).

Hi Carsten,

We can not reproduce on our side. It seems that you used a non-fixed version to install the second instance (2.2.0.1635), please try to use a version greater than 2.2.0.1651 to install the second instance and to upgrade any installation.

BitRock cannot reproduce and notes that the starting point for "install B" above was 2.2.0.1635, which is earlier than the version with the final fixes for this issue (2.2.0.1651).  BitRock says we have to start with 2.2.0.1651 and then upgrade from there to be guaranteed that this will work.

We can not reproduce on our side using the same versions that you are using. This error could be related to old entries in the Windows registry. Could you check it does not exist any "HKEY_LOCAL_MACHINE\Software\MySQL AB" or "HKEY_LOCAL_MACHINE\Software\Sun Microsystems, Inc." in the Windows registry before running your tests? Anyway we have sent a patch to Keith that fixes this issue even if the Windows registry contains old entries.

Keith Russell writes: 
Installer repository updated.

Keith Russell writes: 
Patch available in builds => 2.2.0.1675.

Hi Carsten,

Previous versions to 2.2.0.1675 do not fully support a second installation. As you posted in this case, installing a 2.1.1.1144 as second instance overwrites the Start Menu entries and this is a know issue. You can use any version for the first installation but you should use an Agent version greater than 2.2.0.1675 for the second installation and for the upgrades.

Carsten Segieth writes: 
Hi Andy,

using a 'recent' 2.2.0 as 2nd install (here: 2.2.0.1689), which is then upgraded to 1695, works. Also, if not the 2.2.0.1689 is updated, but the 1st installed 2.1.1.1144, it works. in both these tests we had at the end each 2 correct
 - start menu entries
 - start/stop scripts
 - Win service entries

But I am still not happy that the current 2.2.0.1695 update installer (which we plan to GA) destroys a really usable parallel installation of two 2.1 installs.

I know that after the 2nd 2.1 install the start menu is broken (there is only one entry), but both the start/stop files and the Win service entries are correct for both installs and both 2.1 agentts can really be used in parallel, also with automatic restart after a reboot.
But if one then start the update of one of them to 2.2.0.1695 the result is pretty bad.

My idea was that the update installer can "know" about the problems with the parallel install of older versions and that they do not match a parallel install of 2 current agents, and from this use a different way to detect their service names to keep them.

But perhaps my scenario is not so common on user side and we should stop here with documenting this special update situation.

    Carsten

Mark Leith writes: 
As the installer can not support this, we recommend that users move to the new (support) model of having multiple agent sevices on the same machine. 

Docs: Please document the new procedures for Windows, and note in the upgrade section of the docs.

A note has been added to the 2.2.0 changelog: 

        When performing an installation of &merlin_agent;, installing                                                                                      
        multiple agents could lead to service names (Windows) and                                                                                          
        startup scripts (Unix) being overwritten, corrupted, or                                                                                            
        creating multiple entries. The installer will now ask for a                                                                                        
        different service name, or you can explicitly specify one to                                                                                       
        the installer using the <option>servicename</option>                                                                                               
        option. See                                                                                                                                        
        <xref linkend="option_mysql-monitor-agent-installer_servicename"/>.