[erlang-questions] Re: [erlang-questions 71] Erlang release generation

Per Melin per.melin@REDACTED
Wed Mar 30 10:40:47 CEST 2011


On Wed, Mar 30, 2011 at 1:13 AM, Sam Bobroff <sam@REDACTED> wrote:
> 2011/3/29 Per Melin <per.melin@REDACTED>
>> 2. start.boot.
>> For the same release you get a boot file called foo.boot. But
>> release_handler will barf unless there is a start.boot (which I
>> believe is really irrelevant unless you run in embedded mode with the
>> default scripts). So maybe when you include the option {boot_rel,
>> "foo"} that could mean that foo.boot will instead be called
>> start.boot?
>
> Yes. I've successfully used boot_rel to specify my own boot script. It works
> fine and the specified script is the one that runs if you don't provide one
> on the command line.
> Peace,
> Sam.

I was wrong, kind of. You are correct, you *do* get a start.boot, in
the bin directory. I never saw that before since I usually skip that
directory completely (with the reltool option {excl_sys_filters,
["^bin/"]}) and use my own start script instead.

But if you want to do proper upgrades with release_handler, you'll
need to use the copy of the boot file that was created for you in the
releases/<vsn> directory instead, since each version of the release
has its own boot file. And, as far as I know,
release_handler:unpack_release/1 will not update your bin/start.boot
with subsequent releases, unless you are running in embedded static
emulator diskless mode.

It is quite possible that I've got some part of this wrong. When it
comes to Erlang release handling, I regularly find that to be the
case.



More information about the erlang-questions mailing list