<div dir="ltr">Done that already, to no avail unfortunately.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 2:30 PM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf.wiger@gmail.com" target="_blank">ulf.wiger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>You could perhaps create a setup.appup file in setup-1.5.0/ebin/ with roughly the following content (not tested):</div><div><br></div><div><div>{“1.5.0",</div><div> [{“1.4.6", [{restart_application, setup}]}],</div><div> [{“1.4.6", [{restart_application, setup}]}]</div><div>}.</div><br>BR,</div><div>Ulf W</div><div><div class="h5"><br><div><blockquote type="cite"><div>On 16 Feb 2016, at 13:55, Roberto Ostinelli <<a href="mailto:roberto@widetag.com" target="_blank">roberto@widetag.com</a>> wrote:</div><br><div><div dir="ltr">Thank you Ulf.<div>Anything I can do with an already running system, that obviously doesn't have that PR in? The only application using setup is, as you have guessed, exometer_core.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 1:43 PM, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf.wiger@gmail.com" target="_blank">ulf.wiger@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>It’s true that setup didn’t play well with the release handler [blush].</div><div><br></div><div>That was addressed in the PR you mention.</div><div><br></div><div>The start_setup option was added mainly because some applications (not least exometer) use setup simply to expand and read environment variables, and therefore do not require setup to be started.</div><div><br></div><div>Off the top of my head, I can recall the following reasons to start setup at all:</div><div><br></div><div>- When using it for installation, setup generates a boot script that loads all required apps and sets the code path, then starts setup. Thus, you can fire up a node where only setup is running, but all code and environment data are available. Setup then finds environment variables identifying code hooks to run in different phases of the installation. A corresponding process can be used for upgrades.</div><div><br></div><div>- When making use of setup’s home(), data_dir() and log_dir(), i.e. locations where applications can safely store data and logs. During startup, setup will verify that those directories exist, creating them if necessary. This behavior can be disabled with the env variable -setup verify_directories true | false.</div><div><br></div><div>- You could actually run code hooks even during normal startup. Whether or not that’s a good idea is perhaps up for debate. It is possible, though. </div><div><br></div><div>Predecessors of setup have done more during startup, including reading the boot script and preparing to respond to various configuration queries. But setup currently does little at startup, so most people might prefer it not to start at all. Most functions  - e.g. expanding environment variables or upgrading applications on the fly - are usable even when setup isn’t running.</div><div><br></div><div>BR,</div><div>Ulf W</div><br><div><blockquote type="cite"><div><div><div>On 16 Feb 2016, at 12:27, Roberto Ostinelli <<a href="mailto:roberto@widetag.com" target="_blank">roberto@widetag.com</a>> wrote:</div><br></div></div><div><div><div><div dir="ltr">I found an old PR of Ulf here:<div><a href="https://github.com/uwiger/setup/pull/23" target="_blank">https://github.com/uwiger/setup/pull/23</a><br></div><div><br></div><div>However I don't understand how to use the start_setup option. If any kind soul can help me out it would be great.</div><div><br></div><div>Thanks,</div><div>r.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 12:22 PM, Roberto Ostinelli <span dir="ltr"><<a href="mailto:roberto@widetag.com" target="_blank">roberto@widetag.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dear all,<div>I'm building a release upgrade however I'm encountering an error during the release install:</div><div><font face="monospace, monospace"><br></font></div><div><div><font face="monospace, monospace">1> release_handler:install_release("1.5.0").</font></div><div><font face="monospace, monospace"><0.1497.0>: reason: {'EXIT',{timeout,{sys,get_status,[<0.1497.0>]}}}</font></div><div><font face="monospace, monospace">11:58:30.647 [error] release_handler: cannot find top supervisor for application setup</font></div></div><div><br></div><div>It looks like the application setup [1] does not have a top supervisor, hence the install fails.</div><div><br></div><div>The app setup itself has not been upgraded, it's the same app; however, it is packaged as 1.5.0 in comparison to the 1.4.6 currently running in production.</div><div><br></div><div>Is there any way I can go around this?</div><div><br></div><div>Thanks,</div><div>r.</div><div><br></div><div>[1] <a href="https://github.com/uwiger/setup" target="_blank">https://github.com/uwiger/setup</a></div></div>
</blockquote></div><br></div></div></div>
_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br><a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br></div></blockquote></div><br></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br></div>