Skip to content

[chassis] Record operator for user-initiated DPU reboot/shutdown#4653

Draft
vvolam wants to merge 1 commit into
sonic-net:masterfrom
vvolam:reboot-cause-user-field
Draft

[chassis] Record operator for user-initiated DPU reboot/shutdown#4653
vvolam wants to merge 1 commit into
sonic-net:masterfrom
vvolam:reboot-cause-user-field

Conversation

@vvolam

@vvolam vvolam commented Jun 29, 2026

Copy link
Copy Markdown
Contributor

What I did

Capture the operator who triggers a user-initiated DPU down event so the
DPU reboot-cause history (written by chassisd) can attribute it, mirroring
the NPU reboot-cause user field. Covers both DPU down paths:

  • Rebootreboot_smartswitch_helper
  • Shutdownconfig chassis modules shutdown <DPU>

Companion consumer PR in sonic-platform-daemons (chassisd reads the marker and
populates the user field): sonic-net/sonic-platform-daemons#841

Addresses sonic-net/sonic-buildimage#28149.

How I did it

Both producers write the operator to
/host/reboot-cause/module/<dpu>/prev_reboot_user.txt before the DPU goes
down; chassisd reads and clears this one-shot marker.

  • scripts/reboot_smartswitch_helper: write REBOOT_USER (exported by the
    sourcing reboot script via logname, falling back to whoami) in
    reboot_dpu(), so both the single-DPU (-d) and all-DPU SmartSwitch paths
    are covered.
  • config/chassis_modules.py: persist_dpu_reboot_user() writes the operator
    (SUDO_USER, falling back to getpass.getuser()) and is called in
    shutdown_chassis_module() for the SmartSwitch DPU branch. It is
    best-effort — a marker-write failure logs a warning and never blocks the
    shutdown. Hardware/auto reboots write no marker, so chassisd reports N/A.

How to verify it

Unit tests:

  • tests/chassis_modules_test.py::test_persist_dpu_reboot_user — writes the
    marker with SUDO_USER.
  • test_shutdown_smartswitch_module — asserts persist_dpu_reboot_user("DPU0")
    is invoked on shutdown.

Manual (SmartSwitch DUT):

  1. config chassis modules shutdown DPU0 (or reboot -d DPU0).
  2. cat /host/reboot-cause/module/dpu0/prev_reboot_user.txt → operator name.
  3. After chassisd persists the reboot cause:
    redis-cli -h redis_chassis.server -p 6380 -n 13 HGETALL "REBOOT_CAUSE|DPU0|<name>"
    and show reboot-cause history DPU0User column shows the operator.

Previous command output (if the output of a command-line utility has changed)

No CLI output change. config chassis modules shutdown DPU0 still prints
Shutting down chassis module DPU0. The captured operator surfaces only in
show reboot-cause history <DPU> once chassisd persists the record.

New command output (if the output of a command-line utility has changed)

N/A — no command output changed; only the recorded reboot-cause user field.

DPU down events triggered by an operator did not capture who issued them,
so the DPU reboot-cause history (written by chassisd) showed no 'user',
unlike the NPU reboot-cause flow where the reboot script records logname.

Persist the operator to /host/reboot-cause/module/<dpu>/prev_reboot_user.txt
before a user-initiated DPU goes down, so chassisd can read and clear the
marker to populate the reboot-cause 'user' field:

- reboot_smartswitch_helper: write REBOOT_USER (from the sourcing reboot
  script, falling back to logname/whoami) in reboot_dpu(), covering both the
  single-DPU ('-d') and all-DPU SmartSwitch paths.
- config chassis modules shutdown: write the operator (SUDO_USER, falling
  back to getpass) in shutdown_chassis_module() for the SmartSwitch DPU
  branch. Best-effort: a marker-write failure never blocks the shutdown.

Hardware/auto-detected reboots write no marker, so chassisd reports 'N/A'.

Add unit tests for the shutdown user capture and for persist_dpu_reboot_user.

Signed-off-by: Vasundhara Volam <vvolam@microsoft.com>
@mssonicbld

Copy link
Copy Markdown
Collaborator

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@vvolam

vvolam commented Jun 29, 2026

Copy link
Copy Markdown
Contributor Author

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines successfully started running 1 pipeline(s).

@vvolam

vvolam commented Jun 30, 2026

Copy link
Copy Markdown
Contributor Author

/azp run

@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants