aboutsummaryrefslogtreecommitdiffstats
path: root/lib/sasl/src/release_handler.erl
AgeCommit message (Collapse)Author
2013-12-05Merge branch 'maint'Raimo Niskanen
2013-12-03Fix boot file generation for intermediate releases.Tobias Schlager
A previous refactoring messed up the paths used in the start.boot file used in intermediate releases generated for emulator upgrades.
2013-06-05Merge branch 'siri/unmatched_returns/OTP-10908'Siri Hansen
* siri/unmatched_returns/OTP-10908: Fix unmatched_return warnings in release_handler
2013-05-31Fix unmatched_return warnings in release_handlerSiri Hansen
2013-05-14[sasl] Write erl.ini as utf8, allowing unicode path for root dir and bin dirSiri Hansen
2013-02-22[sasl] Adapt release handling mechanisms to unicodeSiri Hansen
* Update systool_lib:read_term/1 to honour magic encoding comment in file. * Add unicode option to re:compile and re:run when appropriate, allowing e.g. unicode filenames. * systools_make to allow unicode strings in .rel and .app files
2012-10-03Fix release_handler:find_script so it can read regexp in appupsSiri Hansen
2012-03-30Update copyright yearsBjörn-Egil Dahlberg
2012-01-18Fix so remove_release can remove symlinksGustav Simonsson
remove_file in release_handler would fail silently and leave directories in inconsistent states if there was symlinks in a release directory also added a test, otp_9864 to test change
2011-11-30Keep unpack_release backwards compatible with old systools:make_tarSiri Hansen
systools:make_tar has recently been updated to store the .rel file in both releases and releases/<vsn> directories. Ths same commit removed copying of this file from releases to releases/<vsn> in release_handler:unpack_release. This commit adde this copy again to make sure the file is not lost if the tar file was created with an older systools.
2011-11-28Add copy of rel file in releases/<vsn> in release tar fileSiri Hansen
systool:make_tar stores the rel file in the releases directory. When unpacking with release_handler:unpack_release, the file is automatically moved to releases/<vsn>/. If, however, the tar file is unpacked manually, the rel file might not be moved, and the next release unpacked might overwrite the rel file. To overcome this, systools:make_tar now stores a copy of the rel file in releases/<vsn>/ directly and it is not longer necessary to move the file after unpacking. The reason for keeping the file in the releases directory also is that is needs to be extracted separately before the release version <vsn> is known.
2011-11-21Fix dialyzer warnings in release_handlerSiri Hansen
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-17Fix bug in erts upgrade on windowsSiri Hansen
The service which represents the temporary release during erts upgrade on windows was never deleted. This has been corrected. The service is now renamed just after the emulator restart.
2011-11-17Document upgrade instructions restart_new_emulator and restart_emulatorSiri Hansen
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-17Upgrade erts: merge sys.config for tmp release instead of using oldSiri Hansen
The sys.config file used for the temporary release in an erts upgrade is now a hybrid where kernel, stdlib and sasl configuration is taken from the new release, and other configuration is taken from the old release. I.e. similar to how the temporary boot file is created.
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-10-20Add release_handler:which_releases/1joewilliams
This is an extension to which_releases that allows a user to specify the status of the releases they wish to be returned. For instance it allows for quickly determining which release is 'permanent' without the need of parsing the entire release list.
2011-09-05Fix bug in systools:make_tar when path given as just 'ebin'Siri Hansen
If a path was given as ONLY 'ebin' and not for example './ebin', then systools:make_tar would fail with a function_clause exception in filename:join/1. The bug was in systools_make:appDir/1, which tried to find the parent directory of the given path. This function now uses library functions filename:basename and filename:dirname instead of general list manipulations.
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-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-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-03-10Merge branch 'bg/sasl-infinity' into devErlang/OTP
* bg/sasl-infinity: Prepare patch release sasl: Use gen_server:call/3 with infinity timeout OTP-8506 bg/sasl-infinity Use an infinity timeout in all calls to gen_server:call() in the sasl application.
2010-03-08sasl: Use gen_server:call/3 with infinity timeoutBjörn Gustavsson
gen_server:call/2,3 now sets up a monitor to make sure that it will be noticed if the called process dies. Therefore, there is almost never a good reason to use gen_server:call/2 with its default 5 seconds timeout. Use gen_server:call/3 with the 'infinity' timeout instead. To make sure we use the 'infinity' timeout every time, wrap the to call gen_server:call/3 in a local call/1 function in each module.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP