Should Syslog Emergency map to FATAL instead of ERROR3?

[markdascher]

The Log Data Model's Appendix B shows an example mapping from syslog severity levels to SeverityNumber values. All of the syslog severities make sense except for Emergency and Alert, which are apparently swapped.

In syslog, Emergency is the highest severity possible, and Alert is just below Emergency, at least numerically. Quoting from RFC5424:

              0       Emergency: system is unusable
              1       Alert: action must be taken immediately
              2       Critical: critical conditions
              3       Error: error conditions
              4       Warning: warning conditions
              5       Notice: normal but significant condition
              6       Informational: informational messages
              7       Debug: debug-level messages

I'd therefore expect Emergency=FATAL and Alert=ERROR3, but Appendix B does the opposite. Looking through the commit history, tigrannajaryan/rfcs@784e409 seems relevant, possibly in response to this conversation. But it doesn't quite match the mappings suggested in that comment. (The Alert=FATAL mapping was already there anyway.)

Was this just a typo, or is there more to it?

[tigrannajaryan]

Good catch. It is a mistake in the spec. I think Emergency should FATAL2 (more severe than Alert which is FATAL).

Or perhaps Alert should be ERROR4 and Emergency should be FATAL (but I think this is less desirable, Alert seems to be long to FATAL category).

Would you be able to submit a PR to fix this?

[markdascher]

I was assuming Alert would be ERROR4, mainly because FATAL2 isn't used anywhere else yet. And I vaguely remember some discussions about making FATAL a "special" category without four different levels. Obviously that didn't happen technically, but it may still be a useful convention to ensure FATAL is reserved for the most critical events.

On the other hand, if we want to dispel that notion, putting Emergency onto FATAL2 could be a good way to do that.

Without looking at examples, it feels like we're just guessing.

• Linux kernel: KERN_EMERG vs KERN_ALERT
• Linux kernel: pr_emerg vs pr_alert
• FreeBSD: LOG_EMERG vs LOG_ALERT
• NetBSD: LOG_EMERG vs LOG_ALERT
• OpenBSD: LOG_EMERG vs LOG_ALERT

Some examples of ALERT syslogs that might not be FATAL:

FLASH: firmware flash requires a reboot
FLASH: the firmware image will NOT be flashed
user %d attempted to rebuild the alias map
Veriexec: Preventing rename of `%s' to `%s', uid=%u, pid=%u: Lockdown mode.
the %s group is missing, token authentication disabled

There are also plenty of examples that could fit the FATAL category. But there are similar examples for Critical syslogs as well.

[tigrannajaryan]

I was assuming Alert would be ERROR4, mainly because FATAL2 isn't used anywhere else yet. And I vaguely remember some discussions about making FATAL a "special" category without four different levels.

I don't remember a discussion like this and I don't think this was an intent in the design.

However, if we do believe ERROR4 is a better fit for Alert because there are examples of relatively benign logs seen in syslog then I think that is the right way.

Being by a level off is not a huge deal IMO, and if we discover other arguments in favour of shifting the levels by one we can do that later.

The incorrect ordering is much more important, so let's fix that.

[markdascher]

Submitted #2087 with the described changes.

Here's the discussion I was thinking of: https://docs.google.com/document/d/1WQDz1jF0yKBXe3OibXWfy3g6lor9SvjZ4xT-8uuDCiA/edit?disco=AAAAGb77xaY