aboutsummaryrefslogtreecommitdiffstats
path: root/lib/sasl/test/release_handler_SUITE_data
AgeCommit message (Collapse)Author
2015-06-18Change license text to APLv2Bruce Yinhe
2015-02-18Merge branch 'maint'Zandra Hird
2015-01-14[sasl] Make test unreliable of kernel.appupSiri Hansen
release_handler_SUITE:otp_10463_upgrade_script_regexp reads kernel.appup and tries to fetch upgrade instructions for upgrade from current version to current version. The point of the test is to see that release_handler can read an appup with regexps. In some cases, however, kernel.appup does not support upgrade from current to current version, since this is not necessary in real life. Therefore this test is now updated to use a dummy application (release_handler_SUITE_data/regexp_appup/app1) for this test.
2014-10-20[sasl] Remove undocumented upgrade instructionSiri Hansen
The upgrade instruction 'remove_module' was added in OTP R7B (and possibly in a patch in R5B or R6B, ticket OTP-3477), and translates to the low level instruction 'remove', but adds the parameter DepMods (modules on which Mod is dependent). The ticket says that "remove_module should be added for symmetry with the add_module instruction". remove_module was never documented or tested, and it was never mentioned in a release note. It therefore seems to be low risk in removing it. The correct instruction to use when removing a module is {delete_module,Mod} which was added in OTP R10B and which is also documented and tested. This translates to low level instructions 'remove' and 'purge' i.e. the module is brutally purged after setting the current code to old. This hardcoded brutal purge is the reason why PrePurge and PostPurge parameters can not be given with the delete_module instruction. The parameter DepMods which was inclued in the remove_module instruction does not exist for delete_module. From the documentation's point of view, this is the same for add_module, and thus the two instructions {add_module,Mod} and {delete_module,Mod} are now symmetric. However, in the code there is a second instruction for adding a module, {add_module,Mod,DepMods}, which is not documented. To add symmetry even for this, {delete_module,Mod,DepMods} is now also added. Documentation is added for all instructions.
2013-12-09[sasl] Test bugfix in branch 'schlagert/fix_emulator_upgrades'Siri Hansen
OTP-11529
2012-09-13Don't allow {Mod,Vsn} in modules list in .app fileSiri Hansen
It was possible to insert {Mod::atom(),Vsn::term()} instead of Mod::atom() in the modules list in a .app file. This was not visible in the documentation of .app files, but it was visible in the documentation of application:load/[1,2] (where the .app file term can be used directly as first argument). The Vsn part was never used, so this possibility has now been removed.
2011-11-29Add test for upgrade of supervisorSiri Hansen
The test is added in release_handler_SUITE since this makes it possible to test the full upgrade instead of just a simple library test of supervisor:code_change.
2011-11-23Fix release_handler:upgrade_app and downgrade_app when upgrading emulatorSiri Hansen
Changes to the mechanism for upgrading the emulator in OTP R15 was erronously not handled in release_handler:upgrade_app, downgrade_app, upgrade_script and downgrade_script. This has been corrected, including test and documentation.
2011-11-18Merge branch 'siri/sasl/upgrade-erts/OTP-9438'Siri Hansen
* siri/sasl/upgrade-erts/OTP-9438: Fix bug in erts upgrade on windows Add release vsn info to erts_vsn_changed warning Check for sasl application in systools:make_script and make_relup Add syntax check of relup to check_install_release and install_release Add documentation for upgrade from pre R15 to post R15 sasl Handle upgrade from pre R15 to post R15 sasl Step version of sasl to 2.2 for R15 Document upgrade instructions restart_new_emulator and restart_emulator Wait for two restarts in upgrade_restart test Add restart_new_emulator instruction to kernel, stdlib and sasl appups Distinguish restart_new_emulator from restart_emulator in upgrade instructions Upgrade erts: merge sys.config for tmp release instead of using old Allow regexp for version in .appup Restart emulator before running upgrade script when erts is upgraded Conflicts: lib/sasl/src/release_handler.erl lib/sasl/test/release_handler_SUITE.erl
2011-11-17Restart emulator before running upgrade script when erts is upgradedSiri Hansen
If the version of erts differs between two releases, the release handler automatically adds a 'restart_new_emulator' instruction to the upgrade script (relup). Earlier, this instruction was always added at the end of the upgrade script, causing the following sequence of operations during an upgrade (a bit simplified): 1. suspend processes 2. load new code 3. execute code_change functions 4. resume processes 5. restart emulator with new erts version Obviously, this caused the new code to be loaded into the old emulator and this would fail if the beam format had been changed in the new version of the emulator. To overcome this problem, this commit changes the order of the instructions, so for upgrade with changed erts version we now have: 1. restart emulator with new erts, kernel, stdlib and sasl versions, but old versions of all other applications. 2. suspend processes 3. load new code 4. execute code_change functions 5. resume processes This is implemented by creating a temporary release, including new erts, kernel, stdlib and sasl from the new release and all other applications from the old release. A new boot file for this temporary release is created, which includes a new 'apply' instruction to run release_handler:new_emulator_upgrade/2. Then the emulator is restarted using this boot file - and release_handler:new_emulator_upgrade/2 executes the rest of the upgrade script. For downgrade, the order will be as before: 1. suspend processes 2. execute code_change functions with 'down'-indication 3. load old code 4. resume processes 5. restart emulator with old erts version
2011-11-10Remove exec bit from files: info files, dat, batRicardo Catalinas Jiménez
2011-09-20Merge branch 'jw/release_handler_1' into devHenrik Nord
* jw/release_handler_1: General improvements to release_handler_1:get_supervised_procs Conflicts: lib/sasl/src/release_handler_1.erl lib/sasl/test/release_handler_SUITE.erl OTP-9546
2011-09-06General improvements to release_handler_1:get_supervised_procsjoewilliams
The core issues this patch attempts to solve is two fold, 1) have release_handler_1 act slightly differently in two corner cases and 2) clean up the code in get_supervised_procs/0 to remove nested cases and etc. Regarding #1, get_supervised_procs/0 will now call functions to test to see if the supervisor is suspended before attempting to ask it for a list of children. It now will print an error message regarding the suspended supervisor and produce an error that will cause the VM to restart. Previously it would timeout attempting the call to which_children and the VM would restart without any details regarding the reason. The second corner case is if in a child specification a supervisor is incorrectly stated to be a worker and get_modules is called against it. A timeout will occur causing a VM restart. Similar to the last corner case in this patch an error message is printed and an error is emitted causing a VM restart. When first looking into the issue it was hard to discover why my upgrades where failing. All I received during the upgrade process was a timeout and a VM restart, no other information. This patch should help users track down issues like these. Regarding #2, due to the above confusion in trying to figure out what had happened I dug into the code and started tracing it through and found that the nested case statements and etc made it confusing. So I started to rework and clean up, hopefully making this code path clearer to future readers.
2011-09-02Add option purge to release_handler:check_install_releaseSiri Hansen
Given this option, all modules that are to be purged by indicated upgrade,and that can be soft purged, will be purged when all other check of check_install_release have been successfully completed. I added a note under install_release in the reference manual about how to use check_install_release with this new option in order to speed up the execution of install_release. I also added three more test cases for this functionality.
2011-07-07Allow appup instruction delete_module module which is not loadedSiri Hansen
The appup instruction 'delete_module' would cause a crash during upgrade if the module to be deleted was not loaded. The reason was that the release_handler tried to read the version number of the old module after the code path had changed to point to the new version of the application. Thus, if the module had not been loaded before the upgrade, there would no longer be any such module in the path (delete_module indicates that the module is deleted from the new version of the application). This is corrected by letting the release_handler read the old version of the module only if the module is updated - not if it is removed. And it is always read before the code path is changed.
2011-07-04Update code path for all applications that have new versions in a releaseSiri Hansen
If a new version of an application did not include any erlang module changes, the code path of the application was not updasted unless a 'load_object_code' instruction was added for the application. This would be a problem if e.g. only some files in the priv dir were changed, since calls to code:lib_dir or code:priv_dir would then point to the old location of the application. This has been corrected - now code:replace_path/2 will be called for all applications that are changed (i.e. when the application's vsn is changed in the .rel file).
2011-06-15Make release_handler work with windows servicesSiri Hansen
This commit adds test cases from release_handler_SUITE on windows, including some corrections in erlsrv and release_handler.
2011-05-17Add SASL test suiteSiri Hansen