Bug #24938
Gracefully handle ACNET startup errors.
0%
Description
I helped Bobby Santucci debug a framework startup error. His VM was exiting and dumping large, confusing errors. It turned out that acnetd wasn't initialized correctly. This particular error was caused by code in alarm_report.erl, but I would bet other modules are sensitive to this condition, too.
I made changes to the erl-acnet library to gracefully reconnect, if acnetd gets restarted. I don't think we tested what happens when acnetd is missing when we start a front-end. There should be better error messages to understand why starting failed.
History
#1 Updated by Dennis Nicklaus 4 months ago
I've seen that case where "acnetd is missing when we start a front-end" several times, mostly in the earlier years of erlang frontends. It's pretty ugly and yields confusing messages, but once you see them, they are recognizable as a missing acnetd.
#2 Updated by Richard Neswold 4 months ago
- Subject changed from Graceful handle ACNET startup errors. to Gracefully handle ACNET startup errors.
It's pretty ugly and yields confusing messages, but once you see them, they are recognizable as a missing
acnetd.
I think I'll leave this issue open in hopes that we can make it clearer for our users when debugging uncommon situations.
#3 Updated by Richard Neswold 4 months ago
And to be clear, the erl-acnet layer returned {error, -11007}, which is ACNET_SYS. It's the framework unconditionally expecting {ok, TrunkNode} that caused the dump: