Project

General

Profile

Actions

Feature #14546

open

datalink state change system events should mention the link state

Added by Joshua M. Clulow 7 months ago. Updated 7 months ago.

Status:
New
Priority:
Normal
Category:
kernel
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

It would be good to include the link state in the ESC_DATALINK_LINK_STATE system events so that it appears in the structured logs kept by FMA.

By way of example, we can see from various system log messages that the link went down and then up on a NIC port:

root@folgers:~# tail /var/adm/messages | grep 23:04
Feb 26 23:04:16 folgers t4nex: [ID 836064 kern.warning] WARNING: t4nex0: Port 1 link down, reason: Link Down
Feb 26 23:04:16 folgers mac: [ID 486395 kern.info] NOTICE: cxgbe1 link down
Feb 26 23:04:41 folgers mac: [ID 435574 kern.info] NOTICE: cxgbe1 link up, 100000 Mbps, full duplex
Feb 26 23:04:42 folgers /sbin/dhcpagent[532]: [ID 967406 daemon.warning] refreshing state on cxgbe1

But from the machine-readable FM informational log, we cannot tell:

root@folgers:~# fmdump -I -V -p -t 'Feb 26 23:04:16.8368'
TIME                           UUID
Feb 26 2022 23:04:16.836819170 (absent)
nvlist version: 0
        linkid = 4
        link = cxgbe1
        zone = 0
        class = resource.sysevent.EC_datalink.ESC_datalink_link_state
        version = 0x0
        __ttl = 0x1
        __tod = 0x621ab1f0 0x31e0d8e2

Feb 26 2022 23:04:16.836824972 (absent)
nvlist version: 0
        linkid = 4
        link = cxgbe1
        zone = 0
        class = resource.sysevent.EC_datalink.ESC_datalink_link_state
        version = 0x0
        __ttl = 0x1
        __tod = 0x621ab1f0 0x31e0ef8c

Feb 26 2022 23:04:41.924886270 (absent)
nvlist version: 0
        linkid = 4
        link = cxgbe1
        zone = 0
        class = resource.sysevent.EC_datalink.ESC_datalink_link_state
        version = 0x0
        __ttl = 0x1
        __tod = 0x621ab209 0x3720a4fe

Feb 26 2022 23:04:41.924890495 (absent)
nvlist version: 0
        linkid = 4
        link = cxgbe1
        zone = 0
        class = resource.sysevent.EC_datalink.ESC_datalink_link_state
        version = 0x0
        __ttl = 0x1
        __tod = 0x621ab209 0x3720b57f

The downside of including the link state in the message is that people might think it's safe to rely on it, when it likely is not; i.e., by the time a subscriber receives the system event, the link state might have changed again. Consumers of these events must continue to use them as a notification to investigate, not as an iron clad way to know what the current link state is.

I think this downside is of less impact, though, than not being able to find out from the FMA logs what the link state flapped to minutes or hours after it occurred.


Related issues

Related to illumos gate - Feature #11364: Want system event for datalink state changesClosedRobert Mustacchi

Actions
Actions #1

Updated by Joshua M. Clulow 7 months ago

  • Related to Feature #11364: Want system event for datalink state changes added
Actions #2

Updated by Robert Mustacchi 7 months ago

  • Assignee set to Robert Mustacchi
Actions #3

Updated by Electric Monk 7 months ago

  • Gerrit CR set to 2057
Actions #4

Updated by Robert Mustacchi 7 months ago

So the downside is a little more nuanced. In particular, when we get the mac notification that generates this (and also tells vnics, bridges, STREAMS (which gets to libdlpi), it doesn't include what it changed to. So this is also always going to be racy. However, that's the raciness that we've been relying on in all the other clients today where it's a bit more load bearing, so it's probably ok to add this. But you are correct as to why I didn't add this originally.

Actions

Also available in: Atom PDF