This is a Windows specific issue and it is still being researched.
Two major problems are occurring while running the Custom Script Install-Tools/CUS/mysql.cus file in the upgrade - Postinstall process.
A) The mysql.cus script is failing to copy the following new files to the $SPECROOT/mysql/bin/ directory:
- mysql.exe
- mysqladmin.exe
Hence the subsequent scripts will also fail, because those files are no longer in $SPECROOT/mysql/bin/ directory.
The following message is logged in the mysql.log file due the new mysqladmin.exe file is not found (Note that MySQL server is up and running):
Waiting for mysql to start up...
Waiting for mysql to start up...
Final attempt to reach mysql...
**^G Error during mysqladmin --defaults-file=D:/Spectrum/mysql/my-spectrum.cnf -uroot ping
It looks like while the rm (remove) command is still deleting the files, the cp (copy) command is already trying to copy the new files. Hence the new files are not copied and the old files are deleted.
In the $SPECROOT/Install-Tools/CUS/mysql.cus file:
installlog "******* Removing and copying new mysql/bin dir *******"
rm -Rf $MYSQL_DIR/bin >> /dev/null 2>&1
cp -Rf $NEW_MYSQL_DIR/bin $MYSQL_DIR/
In the postinst.hhmm file:
********** Started: Tue Aug 28 17:23:16 2018 **********
running Custom Script Install-Tools/CUS/mysql.cus
cp: cannot create regular file 'd:/spectrum/mysql/bin/mysql.exe': File exists
cp: cannot create regular file 'd:/spectrum/mysql/bin/mysqladmin.exe': File exists
Error(s) occurred. Please see D:/Spectrum/Install-Tools/LOGS/10.3.0.0.341_20180828/mysql.log.
Script Install-Tools/CUS/mysql.cus has FAILED
********** Completed: Tue Aug 28 17:29:00 2018 **********
Workarounds:
1) Rename the following files from the $SPECROOT/mysql/bin directory prior upgrading the CA Spectrum:
- mysql.exe
- mysqladmin.exe
After the upgrade has finished you can delete the renamed files.
2) Modify mysql.cus file to insert a delay in between rm and cp commands. It is tricky to handle this because we have to modify the script in time, while installing.
After the upgrade has launched, check the progress of Extracting files, and go to the $SPECROOT/Install-Tools/CUS/ directory and check the mysql.cus file date. Once it has been updated, then quickly open and add "sleep 60" (without quotes) in between lines 533 and 534 and save it.
installlog "******* Removing and copying new mysql/bin dir *******"
rm -Rf $MYSQL_DIR/bin >> /dev/null 2>&1
sleep 60
cp -Rf $NEW_MYSQL_DIR/bin $MYSQL_DIR/
B) The mysql.cus script is failing to delete the following old file from the $SPECROOT/mysql/bin/ directory:
- mysqld.exe
Even though the mysqld.exe process is no longer running, the $SPECROOT/mysql/bin/mysqld.exe file cannot be deleted. Another Windows process such as DHCP Client has locked the file.
********** Started: Fri Aug 31 13:14:08 2018 **********
running Custom Script Install-Tools/CUS/mysql.cus
rm: delete file "d:/spectrum/mysql/bin/mysqld.exe" failed: Access is denied.
rm: delete dir "d:/spectrum/mysql/bin" failed: The process cannot access the file because it is being used by another process.
Workaround:
Disable Event Log service and reboot the machine to free up the mysqld.exe file.
This problem is similar to this post at stackoverflow:
https://stackoverflow.com/questions/5076618/windows-event-log-service-holding-executable-file-handle
I've also run into this issue, so just adding some of my experiences.
I have a Windows 2008 Service system (have not seen this on 2003 Server), and when I stop my service, and instance of svchost.exe loads the service executable (visible using vmmap.exe or Process Hacker) preventing it from being deleted/overwritten during uninstall/install. The instance of svchost.exe is running the DHCP Client (Dhcp), TCP/IP NetBIOS Helper (lmhosts), and Windows Event Log (EventLog) services.
In our case, we have created a registry entry to make our service executable an event source. (though I'm unsure exactly why we are doing this, or whether we should be doing this).
Empirically, if I remove that registry entry before stopping the service, the executable is not loaded by svchost.exe and all is fine. If the service has already been stopped and executable loaded by svchost.exe, restarting the Event Log service (or killing the process) also frees up the executable.
I'm guessing our service is not well-behaved (perhaps a side effect of being a 32-bit process on 64-bit OS?) or correctly installed, but haven't isolated the issue yet.
Update: It appears this issue is only happening on HP systems (and not Dell or IBM) which is curious. There are HP-specific management components installed, so perhaps one of them is altering the behavior somehow?
The problem occurs on the SpectroSERVER and OneClick hosts.
Thanks,
Silvio