aboutsummaryrefslogtreecommitdiffstats
path: root/lib/sasl/src/release_handler_1.erl
AgeCommit message (Collapse)Author
2011-11-17Add syntax check of relup to check_install_release and install_releaseSiri Hansen
This commit adds a check that all instructions in the relup are valid. Earlier, the last part (after point_of_no_return) was not checked before the actual installation started, meaning that if the relup was hand written, there was a potential for crashing the upgrade here.
2011-11-17Distinguish restart_new_emulator from restart_emulator in upgrade instructionsSiri Hansen
Earlier, there was only one valid instruction to restart the emulator in an appup/relup script, 'restart_new_emulator'. A new instuction, 'restart_emulator', is now added, and the meaning is as follows: 'restart_new_emulator' is mainly for the core applications (erts, kernel, stdlib and sasl), and it indicates that there is new core functionality in the release and the emulator needs to be restarted before executing the upgrade scripts. If this instruction exists, a temporary release will be created which consists of the new version erts, kernel, stdlib and sasl, and the old versions of all other applications. After restarting the emulator with this temporary release, the rest of the upgrade instructions are executed, including loading of new versions. 'restart_emulator' can be used by any application if a restart of the emulator is needed after the upgrade instructions have been executed. In this case, the emulator will be restarted with the new release (i.e. not a tempoarary one) after all other upgrade instructions for all applications have been excecuted.
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-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-08-30Improve performance of upgrade when many processes have old codeSiri Hansen
This commit utilizes the new bif erlang:check_old_code/1 to check if a module has old code in the system or not before running erlang:check_process_code/2. This is to optimize release_handler:install_release (and release_handler:check_install_release). A new test is added which checks that after traversing all processes/modules once and purging all old code, the second run through this part of the code is "sufficiently" much faster. A note is also added in the reference manual for release_handler:install_release about how to go around the efficiency problem of this function.
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-03-21Remove traces of release_handler reading from filesystem when it has Masters ↵Steven Gravell
list There are a couple of places in release_handler and release_handler_1 that assumed it has a disk to read from, which in the case of an erl_prim_loader Loader other than efile is not necessarily true Add check_paths/2 to do the equivalent of check_path/1 for when there is a Masters list Change get_vsn to no longer get sent File paths but instead use the Bin since beam_lib:version being sent a file path causes it to read the local file system Add get_current_vsn/1 as an equivalent to beam_lib:version(code:which(Mod)), but using erl_prim_loader:get_file instead of reading from local file system
2010-05-06Merge branch 'sv/sasl-fix-get_status' into devErlang/OTP
* sv/sasl-fix-get_status: Prepare patch release fix sys:get_status backward compatibility for sasl release_handler_1 OTP-8619 sv/sasl-fix-get_status In R13B04 sys:get_status was modified to invoke format_status/2 in the callback module if the module exports that function. This resulted in a change to the term returned from calling sys:get_status on the supervisor module, since supervisor is a gen_server and gen_server exports format_status. The sasl release_handler_1 module had a dependency on the pre-R13B04 term returned by sys:get_status when invoked on a supervisor, so the R13B04 change broke that dependency. This problem has been fixed by change release_handler_1 to handle both the pre-R13B04 and R13B04 terms that sys:get_status can return from a supervisor.
2010-05-05fix sys:get_status backward compatibility for sasl release_handler_1Steve Vinoski
In R13B04 sys:get_status was modified to invoke format_status/2 in the callback module if the module exports that function. This resulted in a change to the term returned from calling sys:get_status on the supervisor module, since supervisor is a gen_server and gen_server exports format_status. The sasl release_handler_1 module had a dependency on the pre-R13B04 term returned by sys:get_status when invoked on a supervisor, so the R13B04 change broke that dependency. Change release_handler_1 to handle both the pre-R13B04 and R13B04 terms that sys:get_status can return from a supervisor.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP