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

[21 Mar 2007 14:19] Johan Idrén
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.
[26 Mar 2007 8:40] BitRock Merlin
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.
[28 Mar 2007 21:54] Keith Russell
Corrections in versions => 1.1.0.4973
[29 Mar 2007 16:07] Carsten Segieth
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.
[22 Sep 2009 17:03] Andy Bang
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
[22 Sep 2009 17:05] Andy Bang
This is related to Bug #47475.
[24 Sep 2009 14:46] BitRock Merlin
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)
[6 Oct 2009 19:05] Enterprise Tools JIRA Robot
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)
[22 Oct 2009 21:21] Andy Bang
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"
[28 Oct 2009 13:32] BitRock Merlin
Patch sent to Keith.
[12 Nov 2009 20:59] Enterprise Tools JIRA Robot
Keith Russell writes: 
Patch installed in versions => 2.2.0.1537.
[18 Nov 2009 11:32] BitRock Merlin
Hi Carsten,

Our understanding is that patch should be only applied to 2.2.x versions. Could you confirm this?
[18 Nov 2009 12:50] Enterprise Tools JIRA Robot
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.
[12 Jan 2010 12:30] Enterprise Tools JIRA Robot


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

[25 Jan 2010 14:31] BitRock Merlin
Patch sent to Keith. Per Andy request, we also implemented the same approach for Unix platforms.
[28 Jan 2010 16:47] Enterprise Tools JIRA Robot
Keith Russell writes: 
Patch installed in versions => 2.2.0.1611.
[4 Feb 2010 13:32] Enterprise Tools JIRA Robot
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.
[5 Feb 2010 14:21] BitRock Merlin
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.
[5 Feb 2010 14:30] BitRock Merlin
Patch sent to Keith.
[5 Feb 2010 17:10] Enterprise Tools JIRA Robot
Keith Russell writes: 
Patch pushed to installer repository.
[10 Feb 2010 19:45] Enterprise Tools JIRA Robot
Keith Russell writes: 
Patch installed in versions => 2.2.0.1616
[22 Feb 2010 17:32] Enterprise Tools JIRA Robot
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?
[22 Feb 2010 17:58] Carsten Segieth
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.
[23 Feb 2010 17:44] BitRock Merlin
Patch sent to Keith. The Agent Upgrade will ignore the "--servicename" option and it will use the same service name that the previous installation.
[23 Feb 2010 19:15] Enterprise Tools JIRA Robot
Andy Bang writes: 
Patch received from BitRock.
[15 Mar 2010 23:37] Enterprise Tools JIRA Robot
Andy Bang writes: 
Included in build 2.2.0.1651
[24 Mar 2010 16:32] Enterprise Tools JIRA Robot
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).
[25 Mar 2010 15:32] BitRock Merlin
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.
[25 Mar 2010 16:26] Andy Bang
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.
[6 Apr 2010 10:57] BitRock Merlin
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.
[6 Apr 2010 16:35] Enterprise Tools JIRA Robot
Keith Russell writes: 
Installer repository updated.
[6 Apr 2010 21:01] Enterprise Tools JIRA Robot
Keith Russell writes: 
Patch available in builds => 2.2.0.1675.
[22 Apr 2010 14:56] BitRock Merlin
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.
[26 Apr 2010 13:19] Enterprise Tools JIRA Robot
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
[14 May 2010 16:26] Enterprise Tools JIRA Robot
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.
[27 May 2010 13:32] MC Brown
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"/>.