Project

General

Profile

Bug #24938

Gracefully handle ACNET startup errors.

Added by Richard Neswold about 2 months ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
ACSys/FE Framework
Target version:
-
Start date:
09/09/2020
Due date:
% Done:

0%

Estimated time:
Duration:

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 about 2 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 about 2 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 about 2 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:

source:alarm_report.erl@b8fe7862#L33



Also available in: Atom PDF