[erlang-questions] How to Upgrade a Windows Service

[Dick Oyen]

I am a 2 month Erlang OTP newbie. I am trying to do my first release_handler:install_upgrade. It does not complain, but the upgrade functionality does not seem to take effect.

Is there a good instruction on using rebar and release_handler in Windows? I do not have any special requirements (not trying to do distributed Erlang) and I would be joyful to just have
an example project that would work.

My information sources are the release_handler design principles and man pages, the github/basho/rebar, wiki.erlang-web.org/Rebar, Richard Jones' upgrade tutorial. Following some of these has not resulted in my upgrade working and others seem so oriented toward Unix or to their own sample application.

Here is how I am building my release and upgrade: I have two applications and their versions are expressed in three levels, 0.1.2. The name of the application module (qss_app.erl) is not the same as the application (queue_stats_server). Maybe a problem? reltool.config contains {rel, "QSS_SYS", "0.2", [...]}.

I open a git bash shell to build the release. For the first (the non-upgrade) release, I call rebar compile and rebar generate. I then copy the QSS_SYS folder from rel on the development machine and make it C:\QSS_SYS on the target machine (which had been empty of Erlang or QSS_SYS). I create a Windows service with the following command :

C:\QSS_SYS\releases\0.2\qss -config C:\QSS_SYS\releases\0.2\sys.config -s qss_main" -comment "Queue Statistics Server"

qss_main:start() calls application:start('QSS_SYS').

The non-upgrade release works just fine.

Next I make an upgrade. I rename rel\QSS_SYS to rel\QSS_SYS_0.2. The only source code change is to write a new version number into the debug log. I change the app release from 0.1.2 to 0.1.3 in queue_stats_server.app.src. I change the release version from 0.2 to 0.3 in reltool.config.

I use a git bash shell to build the upgrade. I call the following:
rebar compile
rebar generate
rebar generate-appups previous_release=QSS_SYS_0.1
rebar generate-upgrade previous_release=QSS_SYS_0.1

Everything responds with ok.

On the target machine I keep the QSS_SYS Windows service running. I copy the QSS_SYS_0.3.tar.gz to C:\QSS_SYS\Releases. I make sure the path variable points to erl under C:\QSS_SYS. I open an Erlang shell with:
werl -boot c:\QSS_SYS\releases\0.2\start_clean
I call the following:
cd("c:\\qss\\releases").
{ok, Pid} = release_handler:start_link().
release_handler:unpack_release("QSS_SYS_0.2").
release_handler:install_release("0.2").

I think the symptoms have already started because I suspect that I should not have needed to call release_handler:start_link/0. I think there should already be one running with the QSS_SYS windows service. The fact, that I do not know the OTP-appropriate place or way to have it started, makes me think that I have not read the right documentation.

I try to run release_handler:make_permanent("0.3"), but it returns {error,{service_update_failed,service_name_missmatch}}. I think that is because
nonode@REDACTED = node().
I don't know much about nodes, but I think they are associated with distributed Erlang, which I am not using.

It seems too much to expect that someone can see all of my mistakes from this, but I do hope that someone can point me to a reproducible example of going from nothing through a first release, through an upgrade release for an embedded Erlang system as a Windows service.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120510/e463607c/attachment.htm>