CliDeck
PlatformLog in
Workspace

Junos Session Checks Before Maintenance

Runbooks
#junos-users#operational-evidence#runbooks#remote-operations#Runbooks
← Back to Blog

Short answer

Run show system users from Junos operational mode before maintenance to identify listed administrative sessions and coordinate with their owners. Treat this as one input to the handoff. An idle terminal is not permission to interrupt its owner, and an empty list does not establish that management automation has stopped.

Scope and prerequisites

This workflow uses Juniper's Junos command reference and requires the view privilege. Confirm the actual device family, software release, routing engine and command help before adding platform-specific selectors. The generic command is documented across Junos releases; this article does not certify every platform on release 23.4.

Have the maintenance ticket, authorized coordinator and rollback contact available. Do not publish raw session output: usernames, origin addresses and work descriptions can identify people or customers. Capture the minimum operational evidence in the approved private location.

1. Capture the session view

At the operational prompt, use:

show system users

Keep the prompt, capture time and device context with the result. Read the complete header before copying selected rows. A shortened screenshot can omit the context that makes a session understandable.

The table identifies the user, terminal, origin, login time, idle duration and process information. A console origin can be shown as a dash. Preserve the labels printed by your release rather than forcing the output into a template written for another device.

The optional form below avoids resolving origin addresses into hostnames:

show system users no-resolve

It changes the presentation of this view; it does not disconnect anyone. Choose one form consistently for comparable captures.

2. Resolve ownership before interruption

For each relevant row, map the account to an authorized person or service owner using your private operations inventory. Shared accounts require extra coordination: the displayed account alone may not identify the individual using it.

Ask the coordinator to confirm whether each session belongs to the current maintenance, another approved task or an unexplained connection. A terminal can remain idle while its operator is checking another system, waiting for a change window or preserving a recovery path.

If ownership remains unknown, record that uncertainty and stop the disruptive part of the runbook. Do not infer abandoned work from idle time or use logout commands as a shortcut. The read-only capture should produce a handoff decision, not silently make that decision.

3. Check the coverage gap

Juniper explicitly excludes some remote management clients from this display, including Junos XML API clients such as NETCONF. Therefore, use the automation inventory and job scheduler to determine whether an unattended operation overlaps the window.

Do not turn a session count into a universal count of administrators and services. A coordinator should separately confirm the relevant automation window, configuration ownership and recovery access. A successful command establishes that this particular view was available.

On multi-member or multi-chassis systems, the chosen member or chassis matters. Juniper documents selectors for specific MX and TX arrangements; inspect the exact platform help and runbook before using them. A capture from one context should not be labeled as an all-members inspection.

4. Preserve a useful handoff

Record the inspected context, capture time, number of listed rows, unresolved ownership and the person approving the next maintenance step. Keep private identifiers out of the public ticket summary when access is broader than the operations team.

Link the session check to the Junos commit history workflow only if configuration ownership also needs investigation. For capture timing, use UTC and clock uncertainty notes.

Verification note: acceptance criteria

For the actual Junos model and release, verify that the read-only command completes, its context is recorded, every relevant listed session has a coordination outcome and excluded automation has been checked through its owner. Unknown sessions, unsupported selectors or an unconfirmed automation window remain explicit exceptions. These are operator verification criteria; no physical device test or real session transcript is claimed here.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on SSH, serial, browser terminal, and infrastructure operations workflows.

When to use this

Use this guide when:

  • Several commands or checks must be repeated safely.
  • Another engineer, customer, onsite technician, or vendor may need context.
  • The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Workflow

  • Define the purpose, target device, access path, and approved scope.
  • Run read-only checks first and record the expected healthy state.
  • Execute commands from the runbook or handoff plan while watching for stop conditions.
  • Verify the final state with independent checks.
  • Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides