| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is an attempt to correct a failing test case. It the test fails
on having restarted only once, we give it another try to see if the
second restart will happen.
|
|
The appup files for kernel, stdlib and sasl did not contain any
UpFromVsn and DownToVsn. This means that it was not possible to create
a relup file with systool:make_relup if any of these applications had
changed.
This commit adds entries in the appup files for a maximum of two major
releases back - all with only one upgrade instruction:
restart_new_emulator. The point is to allow relups to be generated,
but ensure that no soft upgrade is done for these three applications -
i.e. they will always cause a restart of the emulator prior to all
other upgrade instructions from other applications.
Test cases (appup_test) are added to kernel_SUITE, stdlib_SUITE and
sasl_SUITE. These all check that expected versions are matched in the
appups, and illegal versions (older than two major releases, or in any
other way illegal) do not match. The test is written in a general way
where it is assumed that the version of these applications are stepped
according the the rule that major releases step the second number,
maintenance releases step the third number and patches step the fourth
number.
|
|
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.
|
|
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.
|
|
In order to avoid duplication of upgrade instructions in .appup files,
we now allow regular expressions to specify the UpFrom and DownTo
versions. To be considered a regular expression, the version
identifier must be specified as a binary, e.g.
<<"2\\.1\\.[0-9]+">> will match versions 2.1.x, where x is any number.
|
|
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
|
|
|
|
|
|
* 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
|
|
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
* hw/update-chmod-without-f:
Again: Call chmod without the "-f" flag
OTP-9491
|
|
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.
|
|
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).
|
|
|
|
The service will automatically use the start_erl.exe from the same
directory as erlsrv.exe, and heart will use $PATH, which will
always have the erts bin dir first. The reason is to avoid using old
executables after upgrading erts via the release_handler.
|
|
This commit adds test cases from release_handler_SUITE on windows,
including some corrections in erlsrv and release_handler.
|
|
Commit 7ed11a886fc8fcaf3c2b8324294e2f24e02b0f28 removed the "-f" flag
from chmod calls in Makefiles:
| "-f" is a non-standard chmod option which at least SGI IRIX and HP UX
| do not support. As the only effect of the "-f" flag is to suppress
| warning messages, it can be safely omitted.
Meanwhile, new "chmod -f" calls have been added. This commit removes the
"-f" flag from those new calls.
|
|
|
|
|
|
|
|
* siri/sasl/rb-bugs/OTP-9149:
Bugfix in rb:filter when using 're' (regexp) and 'no'
Don't attempt to do supervisor:delete_child for temporary child
Never fail when stopping rb, and fix file descriptor leak
|
|
Filipe David Manana
OTP-9114: [ftp] Added (type) spec for all exported functions.
OTP-9123: mod_esi:deliver/2 made to accept binary data.
Bernard Duggan
OTP-9124: [httpd] Prevent XSS in error pages.
Michael Santos
OTP-9131: [httpd] Wrong security property names used in documentation.
Garrett Smith
OTP-9157: [httpd] Improved error messages.
Ricardo Catalinas Jim�nez
OTP-9158: [httpd] Fix timeout message generated by mod_esi.
Bernard Duggan
OTP-9202: [httpd] Extended support for file descriptors.
Attila Rajmund Nohl
OTP-9230: The default ssl kind has now been changed to essl.
OTP-9246: [httpc] httpc manager crash because of a handler retry
race condition.
Merge branch 'bmk/inets/inet56_integration' into dev
|
|
There was an inconsistency in the filter function, as
filter([{Key,Regexp,re,no}]) did not work in the same way as
filter([{Key,Value,no}])
The first filter only returned 'proplist' reports, while the second
returned *all* reports that didn't match the Value. This has been
corrected so both filters now return all reports that don't match.
|
|
After a bug fix supervisor does no longer save childspecs for
temporary children. Due to this, all calls to supervisor:delete_child
will fail for temporary children. rb:stop is therefore now rewritten
to only do supervisor:terminate_child.
|
|
rb:stop did sometimes return {error,running}.
This came from supervisor:delete_child and happened when the rb_server
has not yet terminated when this function was called. Instead of
having a separate gen_server call to rb_server for stopping the
process, supervisor:terminate_child is now called. This is a
synchronous function - i.e. it waits for the process to actually
terminate before it returns.
A file descriptor leak in rb:scan_files is corrected. The index file
was never closed after reading.
|
|
log_mf_h are given
The sasl application starts and adds log_mf_h handler if all three
environment variables are given and valid. If any of the variables are
invalid, sasl startup will crash.
Earlier, if one or two of the variables were missing sasl would
successfully start but silently skip adding log_mf_h. This commit
changes this behaviour so that sasl startup will crash if some
variables are given and some are not.
|
|
|
|
* siri/sasl/rb-help-error/OTP-9166:
rb help error
|
|
|
|
Add new option <c>src_tests</c> to systools:make_script and
systools:make_tar. The old option <c>no_module_tests</c> is now
ignored as this is the default behaviour.
|
|
Start and end date for rb:filter/2 was specified as {{Y-M-D},...} in
the help text instead of {{Y,M,D},...}. This has been corrected.
|
|
* sg/fix-diskless-booted-relup:
Remove traces of release_handler reading from filesystem when it has
Masters list
OTP-9142
|
|
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
|
|
bmk/inets/ftp/missing_spec_causes_dialyxer_problems/OTP-9114
Also fixed a bunch of "end-years" (was 2010 but should have been 2011,
which the commit hook not happy with).
|
|
|
|
|
|
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).
|
|
* 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.
|
|
|
|
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.
|
|
* 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.
|
|
|
|
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.
|
|
|
|
|
