Reputation: 6737
I have an application, my_app. It has some other applications it depends on.
my_app.app:
{application, my_app,
[ {description, "My App"},
{vsn, "0.0.1"},
{registered, []},
{applications, [some_dep1,
some_dep2]},
{mod, {my_app_app, []}},
{env, []}
]}.
If either some_dep1
or some_dep2
fail to start, my_app
will also fail to start. So far, so good.
However, if something goes wrong during running the system and some_dep1
blows up (taking out supervisors all the way up the tree), erlang will eventually kill the some_dep1
application; however my_app isn't killed, nor it is notified (that I can find)
Is there a way to handle this? Ideally, I'd like it to restart (just like supervisors handle restarts, with thresholds etc), or alternatively kill any applications that depend on it.
My current thinking is polling for application state, but that seems like a giant hack.
Thanks!
Upvotes: 4
Views: 496
Reputation: 41648
If an application is started as a "permanent" application, the entire Erlang node will go down if the application crashes. This is the default when generating a release, but if you're using application:start
or application:ensure_all_started
, the default type is temporary
, which means that the application just dies silently, as you've observed. Try something like:
application:start(some_dep1, permanent)
or
application:ensure_all_started(my_app, permanent)
There is no supervisor-like thing for applications: if an application crashes, it means that its top-level supervisor has crashed, suggesting that the application doesn't know what more it can do to rectify the problem. (If restarting the application would have fixed the problem, it could equally well have been fixed by increasing the restart limit in the top-level supervisor.) The next level of "supervision" is heart, which restarts an Erlang node if it crashes.
Upvotes: 7