aboutsummaryrefslogtreecommitdiffstats
path: root/lib/sasl/src/systools_rc.erl
AgeCommit message (Collapse)Author
2014-02-18[sasl] Use restart type from .rel when restarting apps during upgradeSiri Hansen
Earlier the 'restart_application' upgrade instruction always cause the application to be restarted as permanent. This could cause the system to end up in an unexpected state after an upgrade. This is now corrected.
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-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-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-02-25Honor start type in .rel files when building relup filesPaul Guyot
Previously, relup file always included an application:start(Application, permanent) apply instruction for every application that appear in the UpTo/DowFrom release file, whatever their start type in the release file. The new implementation fixes this bug by honoring the start type according to the rel(5) format. If the start type is none, no apply line is included in the relup. If the start type is load, the relup includes instruction to only load the application. Otherwise, the relup includes an instruction to start the application to the according type. The fix is implemented by adding a new parameter to the add_application high level appup instruction. This new parameter is documented in appup(5).
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP