[erlang-questions] Deploying on a server with different architecture and version of Erlang

Vineet Naik naikvin@REDACTED
Sat Dec 15 16:36:24 CET 2012


On Sat, Dec 15, 2012 at 3:03 AM, Anders Nygren <anders.nygren@REDACTED>wrote:

> On Fri, Dec 14, 2012 at 11:09 AM, Vineet Naik <naikvin@REDACTED> wrote:
> > On Fri, Dec 14, 2012 at 9:39 PM, Daniel Luna <daniel@REDACTED> wrote:
> >>
> >> If this fixed your problem you have missing dependencies in your
> >> .app.src file.  We always run {mod_cond, derived} here and it works
> >> like a charm.
> >>
> >> Until you miss to add a dependency in the .app.src file that is.
> >
> >
> > Hi Daniel,
> >
> > I am am not able to exactly understand which dependencies are to be
> added in
> > app.src.
> >
> > My code directly depends upon just two - emysql and exmpp (Not the
> > processone version
> > but this one [1] which is rebar compatible). Besides these, kernel and
> > stdlib are defined.
> >
> > While creating a release on my development machine I could fix some
> initial
> > errors by
> > adding inets, sasl and crypto. That solved the problems with mod_cond
> still
> > being 'derived'
> >
> > Today while creating a release on the server (where the app will be
> deployed
> > eventually),
> > it again failed with `{"init terminating in do_boot",{'cannot
> > load',X,get_file}}` kind of errors
> > and adding 'X' to app.src didn't work. Changing mod_cond to 'all' worked.
> >
> > Now if I check the libraries in rel/<release-bundle>/lib directory, there
> > are a lot of them
> > but not all are added to app.src and it still works.
> >
> > How to decide which ones go in app.src and which don't?
> >
>
> The ones to put in the .app.src are the applications that MUST be
> started* before Your app is started.
> This information is used when the .boot script is created, so that all
> the applications are started in the correct order.
>
> *, Yes, I know the documentation says that stdlib shall always be
> included even though stdlib doesn't have any processes that needs to
> be started.
>

Ok, now I get it. In fact it's mentioned in LYSE which is one of the
resources
I am referring to.

>From LYSE[1]

{mod_cond, all | app | ebin | derived | none}This controls the module
> inclusion policy. Picking none means no modules will be kept. That's not
> very useful. The derived option means that Reltool will try to figure out
> what modules are used by other modules which are already included and add
> them in that case. Setting the option to app will mean that Reltool keeps
> all the modules mentioned in the app file and those that were derived.
> Setting it to ebin will keep those in the ebin/directory and the derived
> ones. Using the option all will be a mix of using ebin and app. That's the
> default value.



In the process of desperately trying to get the release working I had
forgotten of having read this.

In free time, I will try creating the release from scratch just using
reltool
(without rebar). Probably that will make things more clear for me.

Thanks

[1] http://learnyousomeerlang.com/release-is-the-word#releases-with-reltool


>
>
> > [1]: Rebar compatible fork of exmpp https://github.com/Zert/exmpp
> >
> > Thanks,
> > Vineet
> >
> >>
> >> Cheers,
> >>
> >> Daniel
> >>
> >> On 14 December 2012 09:54, Vineet Naik <naikvin@REDACTED> wrote:
> >> > IRC to the rescue! Changed mod_cond from derived to all
> >> > and it solved the problem.
> >> >
> >> > Thanks a lot
> >> > Vineet
> >> >
> >> >
> >> > On Fri, Dec 14, 2012 at 7:11 PM, Vineet Naik <naikvin@REDACTED>
> wrote:
> >> >>
> >> >> Now I got past this error, it was a mistake from my side. I didn't
> >> >> create
> >> >> the node on the server before running generate but copied files from
> my
> >> >> dev machine. After creating node and with some tweaking to the
> reltool
> >> >> config,
> >> >> release is generated on the prod server but fails on startup with,
> >> >>
> >> >> {"init terminating in do_boot",{'cannot
> load',error_handler,get_file}}
> >> >>
> >> >> From erlang docs[1]
> >> >>
> >> >> "Init terminating in do_boot ()" - The primitive Erlang boot sequence
> >> >> was
> >> >> terminated, most probably because the boot script has errors or
> cannot
> >> >> be
> >> >> read. This is usually a configuration error - the system may have
> been
> >> >> started with a faulty -boot parameter or with a boot script from the
> >> >> wrong
> >> >> version of OTP.
> >> >>
> >> >> How can I check whether boot script running from the wrong version of
> >> >> OTP
> >> >> is
> >> >> the problem?
> >> >>
> >> >> [1]: http://www.erlang.org/doc/apps/erts/crash_dump.html#id71973
> >> >>
> >> >> Regards,
> >> >> Vineet
> >> >>
> >> >> On Fri, Dec 14, 2012 at 4:05 PM, Vineet Naik <naikvin@REDACTED>
> wrote:
> >> >>>
> >> >>> Hello,
> >> >>>
> >> >>> Now that I have successfully built a release of my app using rebar,
> I
> >> >>> am
> >> >>> stuck at
> >> >>> deploying the packaged release because the server I want to deploy
> to
> >> >>> has
> >> >>> different
> >> >>> version of erlang and different architecture from my development
> >> >>> machine.
> >> >>>
> >> >>> Development Env
> >> >>> -------------------------
> >> >>> i686 i686 i386 GNU/Linux
> >> >>> Erlang R14B04
> >> >>> erts-5.8.5
> >> >>>
> >> >>> Remote Server
> >> >>> ----------------------
> >> >>> x86_64 GNU/Linux
> >> >>> Erlang R13B03
> >> >>> erts-5.7.4
> >> >>>
> >> >>> I tried compiling on the server but it's failing with a series of
> >> >>> errors
> >> >>> such as
> >> >>>
> >> >>> ERROR: Unable to generate spec: Mandatory application kernel is not
> >> >>> included in [{app,crypto,false,undefined,
> >> >>>
> >> >>> "/usr/lib/erlang/lib/crypto-1.6.3",
> >> >>>
> >> >>> ["/usr/lib/erlang/lib/crypto-1.6.3"],
> >> >>>
> >> >>> "1.6.3","crypto-1.6.3",
> >> >>>                                                   .....
> >> >>>
> >> >>> I have two questions:
> >> >>>
> >> >>> 1. Is this due to the old version of erlang? And considering that I
> >> >>> have
> >> >>> ejabberd and rabbitmq-server running in production on the same
> server
> >> >>> can I upgrade erlang to R14B04 on it without having to take them
> down
> >> >>> for
> >> >>> much
> >> >>> time?
> >> >>>
> >> >>> 2. What is the recommended strategy for developing and deploying
> >> >>> erlang
> >> >>> code on
> >> >>> differently configured servers?
> >> >>>
> >> >>> Thanks,
> >> >>> Vineet
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Vineet Naik
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Vineet Naik
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > erlang-questions mailing list
> >> > erlang-questions@REDACTED
> >> > http://erlang.org/mailman/listinfo/erlang-questions
> >> >
> >
> >
> >
> >
> > --
> > Vineet Naik
> >
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
>



-- 
Vineet Naik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121215/7cbd8233/attachment.htm>


More information about the erlang-questions mailing list