### Install TPC Package Examples

Source: https://github.com/sonic-net/sonic/blob/master/doc/sonic-application-extension/tpcm_app_ext.md

Provides examples of installing TPC packages using the 'sonic-package-manager install' command. Demonstrates installation from a URL, SCP, SFTP, and local filesystem, specifying a custom name for the TPC package.

```bash
admin@sonic:~$ sudo sonic-package-manager install httpd:latest --name my_httpd

```

```bash
Install from url:
admin@sonic:~$ sudo sonic-package-manager install --from-tarball https://tpc.local-server.com/home/tpcs/httpd.tar.gz --name=my_url_httpd

```

```bash
Install from scp:
admin@sonic:~$ sudo sonic-package-manager install --from-tarball scp://username@10.171.112.156/home/tpcs/httpd.tar.gz --name my_scp_httpd

```

```bash
Install from sftp:
admin@sonic:~$ sudo sonic-package-manager install --from-tarball sftp://username@10.171.112.156/home/tpcs/httpd.tar.gz --name my_sftp_httpd

```

```bash
Install from local FS:
admin@sonic:~$ sudo sonic-package-manager install --from-tarball /usb1/tpcs/httpd.tar.gz --name my_local_httpd

```

--------------------------------

### Install and Configure KVM for Virtualization

Source: https://github.com/sonic-net/sonic/blob/master/doc/test/Bring-up_Sonic-VS_on_Cloud_top.md

This section covers the installation and configuration of KVM, libvirt, and related utilities necessary for running virtual machines. It includes checking for virtualization support, installing packages, enabling the libvirtd service, and adding the user to relevant groups.

```bash
kvm-ok  # If command not found, install the required packages

sudo apt install -y qemu-kvm virt-manager libvirt-daemon-system virtinst libvirt-clients bridge-utils
sudo systemctl enable --now libvirtd
sudo systemctl start libvirtd

sudo systemctl status libvirtd

sudo usermod -aG kvm $USER
sudo usermod -aG libvirt $USER
# Log out and log back in

sudo systemctl stop libvirtd
sudo setfacl -m user:$USER:rw /var/run/libvirt/libvirt-sock
sudo systemctl enable libvirtd
sudo systemctl start libvirtd

sudo apt install -y ebtables
```

--------------------------------

### ZTP Configuration Example (JSON)

Source: https://github.com/sonic-net/sonic/blob/master/doc/ztp/ztp.md

An example ZTP JSON configuration file demonstrating firmware installation, config_db.json download, post-provisioning script execution, and connectivity checks.

```json
{
  "ztp": {
    "01-firmware": {
      "install": {
        "url": "http://192.168.1.1/broadcom-sonic-v1.0.bin"
      }
    },
    "02-configdb-json": {
      "dynamic-url": {
        "source": {
          "prefix": "http://192.168.1.1/",
          "identifier": "hostname",
          "suffix": "_config_db.json"
        }
      }
    },
    "03-provisioning-script": {
      "plugin": {
        "url":"http://192.168.1.1/post_install.sh"
      },
      "reboot-on-success": true
    },
    "04-connectivity-check": {
      "ping-hosts": [ "10.1.1.1", "yahoo.com" ]
    }
  }
}
```

--------------------------------

### Installing 3rd Party Docker Image using sonic-package-manager (Shell)

Source: https://github.com/sonic-net/sonic/blob/master/doc/sonic-application-extension/sonic-application-extention-hld.md

Example commands demonstrating how to add a 3rd party Docker image repository and install it using a provided manifest URL. The manifest is then saved locally for future use.

```shell
admin@sonic:~$ sudo sonic-package-manager repository add collectd puckel/docker-collectd
admin@sonic:~$ sudo sonic-package-manager install collectd --manifest https://some-server/manifests/collectd/manifest.json
```

--------------------------------

### Start SONiC-P4 Testbed

Source: https://github.com/sonic-net/sonic/wiki/SONiC-P4-Software-Switch

This script initiates the SONiC-P4 testbed setup, including starting Docker containers for hosts and switches, creating network links between them, and configuring interfaces and routes.

```bash
./start.sh
```

--------------------------------

### SONiC Build Environment Setup Script

Source: https://github.com/sonic-net/sonic/wiki/Build-Broadcom-Opennsl-and-SAI

A bash script designed to be run inside a SONiC build slave Docker container. It installs necessary kernel build packages, fixes symbolic links for kernel modules, and sets up the kernel source directory for building.

```bash
#!/bin/bash -x

function set_kernel_version()
{
    COMMON=$(ls /sonic/target/debs/linux-headers*common*.deb)
    TMP=${COMMON//\/sonic\/target\/debs\/linux-headers-/}
    VERSION=${TMP//-common*/}
    
    echo "Version: $VERSION"
}

function fix_build_symbolic_links()
{
    # Fix source code symbolic links until Broadcom fix build issue.
    sudo rm -rf /lib/modules/$VERSION-amd64/build
    sudo rm -rf /lib/modules/$VERSION-amd64/source
    sudo ln -s /usr/src/linux-headers-$VERSION-common/ /lib/modules/$VERSION-amd64/source
    sudo ln -s /usr/src/linux-headers-$VERSION-amd64/  /lib/modules/$VERSION-amd64/build
    sudo ln -s /usr/src/linux-headers-$VERSION-amd64/include/generated/ /usr/src/linux-headers-$VERSION-common/include/generated
    sudo ln -s /usr/src/linux-headers-$VERSION-amd64/arch/x86/include/generated/ /usr/src/linux-headers-$VERSION-common/arch/x86/include/generated
    sudo ln -s /usr/src/linux-headers-$VERSION-amd64/include/config/ /usr/src/linux-headers-$VERSION-common/include/config
    sudo cp /usr/src/linux-headers-$VERSION-amd64/Module.symvers /usr/src/linux-headers-$VERSION-common/Module.symvers
    
    ls /lib/modules
}

sudo apt-get -y install linux-kbuild-3.16 linux-compiler-gcc-4.8-x86
sudo dpkg -i /sonic/target/debs/linux-headers-*.deb

set_kernel_version
fix_build_symbolic_links

export KERNEL_SRC=/usr/src/linux-headers-$VERSION-common

fakeroot debian/rules -j20 -B binary
```

--------------------------------

### Install SONiC Image

Source: https://github.com/sonic-net/sonic/wiki/How-to-Deploy-SONiC

Makes the SONiC binary executable and then runs the installation script. This is performed on the device after the image has been copied.

```bash
$ chmod +x ./sonic-generic.bin
$ ./sonic-generic.bin
```

--------------------------------

### Example Running Configuration (JSON)

Source: https://github.com/sonic-net/sonic/blob/master/doc/config-generic-update-rollback/Json_Change_Application_Design.md

Illustrates the structure of a typical running configuration in JSON format, showing nested objects for different configuration tables like DEVICE_NEIGHBOR and DHCP_SERVER.

```JSON
{
    "DEVICE_NEIGHBOR": {
        "Ethernet8": {
            "name": "Servers1",
            "port": "eth0"
        },
        "Ethernet80": {
            "name": "Servers19",
            "port": "eth0"
        }
    },
    "DHCP_SERVER": {
        "192.0.0.1": {},
        "192.0.0.2": {}
    },
}
```

--------------------------------

### GET /container

Source: https://github.com/sonic-net/sonic/blob/master/doc/sonic-application-extension/sonic-application-extension-guide.md

Retrieves container-related properties.

```APIDOC
## GET /container

### Description
Retrieves container-related properties.

### Method
GET

### Endpoint
/container

### Response
#### Success Response (200)
- **privileged** (string) - Indicates if the container is started in privileged mode. Possible values: "true", "false".
- **volumes** (list of strings) - A list of volume mounts for the container. Format: "<src>:<dest>:<options>".
- **mounts** (list of objects) - A list of detailed mount configurations for the container.
  - **id** (string) - Unique identifier for the mount.
  - **source** (string) - The source path of the mount.
  - **target** (string) - The target path within the container.
  - **type** (string) - The type of the mount (e.g., "bind", "tmpfs").
- **tmpfs** (list of strings) - A list of tmpfs mount configurations.
- **environment** (dict) - A dictionary of environment variables for the Docker container (key=value).

#### Response Example
```json
{
  "privileged": "false",
  "volumes": [
    "/path/on/host:/path/in/container:rw"
  ],
  "mounts": [
    {
      "id": "data-volume",
      "source": "/var/lib/sonic/data",
      "target": "/data",
      "type": "bind"
    }
  ],
  "tmpfs": [
    "/run"
  ],
  "environment": {
    "DEBUG": "1"
  }
}
```
```

--------------------------------

### Example Device Dictionary Initialization

Source: https://github.com/sonic-net/sonic/blob/master/doc/storagemond/storagemond-hld.md

Illustrates the state of the 'devices' dictionary after the get_storage_devices() function has been executed, showing discovered storage disks as keys.

```python
devices = {
'mmcblk0' : None
'sda'     : None
}
```

--------------------------------

### Initialize SonicV2Connector (Python)

Source: https://github.com/sonic-net/sonic/blob/master/doc/database/multi_database_instances.md

Demonstrates the initialization of the SonicV2Connector class, showing how to create an instance and connect to a database. The example highlights a simplified connection without explicit host parameters.

```python
self.appdb = SonicV2Connector()
self.appdb.connect(self.appdb.APPL_DB)
```

--------------------------------

### SONiC Package JSON Entry Example

Source: https://github.com/sonic-net/sonic/blob/master/doc/sonic-application-extension/sonic-application-extention-hld.md

An example of how a SONiC package is represented in the `packages.json` file after installation from a tarball. It includes repository, version, status, and image ID.

```json
{
  "featureA": {
    "repository": "featureA",
    "installed-version": "1.0.0",
    "status": "installed",
    "image_id": "9ab631f37d1d"
  }
}
```

--------------------------------

### GET /cli

Source: https://github.com/sonic-net/sonic/blob/master/doc/sonic-application-extension/sonic-application-extension-guide.md

Retrieves CLI plugin information.

```APIDOC
## GET /cli

### Description
Retrieves CLI plugin information. NOTE: This endpoint will be deprecated and replaced with a YANG module file path in later versions.

### Method
GET

### Endpoint
/cli

### Response
#### Success Response (200)
- **mandatory** (boolean) - Indicates if the CLI functionality is mandatory for the package. Default: False.
- **show_cli_plugin** (list of strings) - List of paths to plugins for the `sonic-utilities show` CLI command.
- **config_cli_plugin** (list of strings) - List of paths to plugins for the `sonic-utilities config` CLI command.
- **clear_cli_plugin** (list of strings) - List of paths to plugins for the `sonic-utilities sonic-clear` CLI command.
- **auto_generate_config** (boolean) - ON/OFF trigger for auto-generation of the CLI command `config`. Default: false.
- **auto_generate_show** (boolean) - ON/OFF trigger for auto-generation of the CLI command `show`. Default: false.
- **auto_generate_config_source_yang_modules** (list of strings) - If set, config CLI auto-generation will only apply to specified YANG modules. The YANG module is referenced by the name recorded in labels (which should match the name of the module).
- **auto_generate_show_source_yang_modules** (list of strings) - If set, show CLI auto-generation will only apply to specified YANG modules. The YANG module is referenced by the name recorded in labels (which should match the name of the module).

#### Response Example
```json
{
  "mandatory": false,
  "show_cli_plugin": [
    "/usr/local/bin/show_lldp.py"
  ],
  "config_cli_plugin": [
    "/usr/local/bin/config_vlan.py"
  ],
  "clear_cli_plugin": [],
  "auto_generate_config": true,
  "auto_generate_show": false,
  "auto_generate_config_source_yang_modules": [],
  "auto_generate_show_source_yang_modules": []
}
```
```

--------------------------------

### Example: Show MUX Cable Configuration (CLI)

Source: https://github.com/sonic-net/sonic/blob/master/doc/dualtor/dualtor_active_standby_hld.md

Provides an example of retrieving MUX cable configuration in JSON format. The output details peer TOR information, link prober settings (interval, timeout), and the state and server details for each port.

```bash
eg: show muxcable config --json
output:
{
   “MUX_CABLE”: {
       “PEER_TOR”: “10.10.10.3”,
       “LINK_PROBER”: {
           “INTERVAL”: {
               “IPv4”: 100,
               “IPv6”: 1000,
           },
           “TIMEOUT”: 3,
       },
       “PORTS”: {
           “ETHERNET0”: {
               “STATE”: “ACTIVE”,
               “SERVER”: {
                   “IPv4”: “192.168.1.10”,
                   “IPv6”: “fc00::75”
               }
           },
           “ETHERNET4”: {
               “STATE”: “AUTO”,
               “SERVER”: {
                   “IPv4”: “192.168.1.40”,
                   “IPv6”: “fc00::ab”
               }
           }
        }
     }
}
```

--------------------------------

### Create TPC Manifest Example

Source: https://github.com/sonic-net/sonic/blob/master/doc/sonic-application-extension/tpcm_app_ext.md

Illustrates the command syntax for creating a new manifest file for a TPC package. It requires the manifest name and a JSON file containing the manifest details.

```bash
sonic-package-manager manifests create <manifest-name> --from-json <jsonfile>

```

--------------------------------

### Configuration Example: System LAG ID Boundaries

Source: https://github.com/sonic-net/sonic/blob/master/doc/voq/lag_hld.md

Example configuration snippet from chassisdb.conf defining the start and end range for system LAG IDs. These boundaries are loaded and set in CHASSIS_APP_DB.

```ini
SYSTEM_LAG_ID_START=1
SYSTEM_LAG_ID_END=100
```

--------------------------------

### Install SONiC SWI Image on Arista (EOS CLI)

Source: https://github.com/sonic-net/sonic/wiki/Quick-Start

This snippet demonstrates how to install a SONiC SWI image on Arista hardware using the EOS command-line interface. It involves copying the image to flash and then configuring the system to boot from it.

```text
eos#copy http://192.168.2.10/sonic-aboot-broadcom.swi flash:
Copy completed successfully.
eos(config)#boot system flash:sonic-aboot-broadcom.swi
eos(config)#reload
System configuration has been modified. Save? [yes/no/cancel/diff]:no
Proceed with reload? [confirm] [type enter]

Broadcast message from root@eos
        (unknown) at 8:22 ...

..... (boot messages)


Debian GNU/Linux 8 sonic ttyS0

sonic login: 
```

--------------------------------

### Sample media_settings.json Configuration

Source: https://github.com/sonic-net/sonic/blob/master/doc/media-settings/Media-based-Port-settings.md

This JSON file defines global and port-specific media settings. It includes configurations for different port types (e.g., 1-32, 2,4,6,8) and specific media types (e.g., AMPHENOL-1234, MOLEX-5678, QSFP28-40GBASE-CR4-1M, DELL-5678). Each media type can have 'preemphasis' and 'idriver' settings defined per lane.

```json
{
    "GLOBAL_MEDIA_SETTINGS": {
        "1-32": {
            "AMPHENOL-1234": {
                "preemphasis": {
                    "lane0":"0x001234",
                    "lane1":"0x001234",
                    "lane2":"0x001234",
                    "lane3":"0x001234"
                },
                "idriver": {
                    "lane0":"0x2",
                    "lane1":"0x2",
                    "lane2":"0x2",
                    "lane3":"0x2"
                }
            },
            "MOLEX-5678": {
                "preemphasis": {
                    "lane0":"0x005678",
                    "lane1":"0x005678",
                    "lane2":"0x005678",
                    "lane3":"0x005678"
                },
                "idriver": {
                    "lane0":"0x1",
                    "lane1":"0x1",
                    "lane2":"0x1",
                    "lane3":"0x1"
                }
            },
            "QSFP28-40GBASE-CR4-1M":{
                "preemphasis": {
                    "lane0":"0x005678",
                    "lane1":"0x005678"
                },
                "idriver": {
                    "lane0":"0x1",
                    "lane1":"0x1"
                }
            }
        },
	"2,4,6,8": {
	    "Default": {
				"preemphasis": {
					"lane0":"0x612233",
					"lane1":"0x512233",
					"lane2":"0x412244",
					"lane3":"0x343322"
				},
				"idriver": {
					"lane0":"0x1",
					"lane1":"0x2",
					"lane2":"0xd",
					"lane3":"0x1"
				}
	    }
	}
        },
	"PORT_MEDIA_SETTINGS": {
	    "1": {
			"Default": {
				"preemphasis": {
					"lane0":"0x112233",
					"lane1":"0x112233",
					"lane2":"0x112244",
					"lane3":"0x443322"
				},
				"idriver": {
					"lane0":"0xb",
					"lane1":"0xc",
					"lane2":"0xd",
					"lane3":"0xa"
				}
			},
			"DELL-5678": {
				"preemphasis": {
					"lane0":"0x102233",
					"lane1":"0x132233",
					"lane2":"0x152244",
					"lane3":"0x413322"
				},
 			 "idriver": {
 				"lane0":"0xc",
 				"lane1":"0xc",
 				"lane2":"0xd",
 				"lane3":"0xb"
 			 }
		}
	}
        }
}

```

--------------------------------

### Get Request with CONFIG_YANG Schema

Source: https://github.com/sonic-net/sonic/blob/master/doc/mgmt/gnmi/SONiC_GNMI_Server_Interface_Design.md

Illustrates a GET request using the SONiC Yang schema to fetch configuration data. This example shows how Yang models are referenced in the path and the structure of the response.

```protobuf
++++++++ Sending get request: ++++++++
path {
    origin: "sonic_yang"
    elem {name: "CONFIG_DB"} elem {name: "localhost"} elem {name: "sonic-device_neighbor:sonic-device_neighbor"}
}
encoding: JSON_IETF
++++++++ Recevied get response: ++++++++
notification {
    update {
        path {
            origin: "sonic_yang"
            elem {name: "CONFIG_DB"} elem {name: "localhost"} elem {name: "sonic-device_neighbor:sonic-device_neighbor"} elem {name: "sonic-device_neighbor:DEVICE_NEIGHBOR"} elem {name: "DEVICE_NEIGHBOR_LIST" key {key: "name" value: "Ethernet8"}}
        }
        val {
            json_ietf_val: "{\"name\": \"Servers1\",\"port\": \"eth0\"}"
        }
    }
    update {
        path {
            origin: "sonic_yang"
            elem {name: "CONFIG_DB"} elem {name: "localhost"} elem {name: "sonic-device_neighbor:sonic-device_neighbor"} elem {name: "sonic-device_neighbor:DEVICE_NEIGHBOR"} elem {name: "DEVICE_NEIGHBOR_LIST" key {key: "name" value: "Ethernet96"}}
        }
        val {
            json_ietf_val: "{\"name\": \"Servers23\",\"port\": \"eth0\"}"
        }
    }
}
```

--------------------------------

### Example Initial Extension Configuration (JSON)

Source: https://github.com/sonic-net/sonic/blob/master/doc/sonic-application-extension/sonic-application-extention-hld.md

This JSON snippet demonstrates the structure for providing initial configuration to a SONiC package. It specifies settings like CPU reporting intervals, which are loaded into the CONFIG DB during installation.

```json
{
  "package": {
    "init-cfg": {
      "CPU_REPORT": {
        "global": {
          "report-interval": "5"
        }
      }
    }
  }
}
```

--------------------------------

### Example platform_components.json for Firmware Package

Source: https://github.com/sonic-net/sonic/blob/master/doc/fwutil/fwutil.md

A JSON example of the 'platform_components.json' file, which is crucial for the 'fwutil update all' command. It defines chassis, components, their firmware files, and versions.

```json
{
    "chassis": {
        "Chassis1": {
            "component": {
                "BIOS": {
                },
                "CPLD": {
                    "firmware": "cpld.bin",
                    "version": "10"
                },
                "SSD": {
                    "firmware": "ssd.bin",
                    "version": "5"
                }
            }
        }
    }
}

```

--------------------------------

### Install SONiC ONIE Image via HTTP

Source: https://github.com/sonic-net/sonic/wiki/Quick-Start

This snippet shows the commands to configure network settings and install a SONiC image from an HTTP server within the ONIE environment. It requires the switch to have network connectivity to the HTTP server hosting the SONiC binary.

```bash
ONIE:/ # ifconfig eth0 192.168.0.2 netmask 255.255.255.0
ONIE:/ # ip route add default via 192.168.0.1
ONIE:/ # onie-nos-install http://192.168.2.10/sonic-broadcom.bin
```

--------------------------------

### Database Initialization Script (Shell)

Source: https://github.com/sonic-net/sonic/blob/master/doc/database/multi_database_instances.md

This script, docker-database-init.sh, serves as the entrypoint for the database Docker container. It handles the initialization of the database services by copying either a customized database configuration from /etc/sonic/ or a default configuration from /etc/default/ to the running location. It also uses a Jinja2 template to generate the supervisord.conf file, which dictates how many Redis instances will be started.

```shell
#!/bin/bash

# Check for customized database configuration
if [ -f "/etc/sonic/database_config.json" ]; then
    cp /etc/sonic/database_config.json /var/run/redis/sonic-db/
else
    # Use default configuration if no customized one is found
    cp /etc/default/sonic-db/database_config.json /var/run/redis/sonic-db/
fi

# Generate supervisord.conf using Jinja2 template
# This part would involve a templating engine like Jinja2 to process supervisord.conf.j2
# Example placeholder:
# jinja2 /etc/supervisor/supervisord.conf.j2 /var/run/redis/sonic-db/database_config.json > /etc/supervisor/supervisord.conf

# Execute the original entrypoint program (e.g., supervisord)
# exec /usr/bin/supervisord

# Placeholder for actual script logic
echo "Database initialization script executed."

```

--------------------------------

### Example reboot.conf Configuration

Source: https://github.com/sonic-net/sonic/blob/master/doc/reboot/Reboot_BlockingMode_HLD.md

This snippet demonstrates the structure and content of a typical reboot.conf file. It shows how to enable blocking mode, set a custom timeout, and activate the timer for the reboot command.

```ini
blocking_mode=true
blocking_mode_timeout=10
show_timer=true
```

--------------------------------

### Install SONiC SWI Image on Arista (EOS Bash Shell)

Source: https://github.com/sonic-net/sonic/wiki/Quick-Start

This snippet shows an alternative method for installing a SONiC SWI image on Arista hardware by executing commands from the EOS bash shell. It involves downloading the image, modifying the boot configuration, and rebooting.

```text
eos#bash
bash# cd /mnt/flash
bash# wget http://192.168.2.10/sonic-aboot-broadcom.swi
bash# sed -Ei 's/SWI=.*/SWI=flash:sonic-aboot-broadcom.swi/' boot-config
bash# reboot

... (boot messages)

sonic login: 
```

--------------------------------

### GET /service/fast-shutdown/before

Source: https://github.com/sonic-net/sonic/blob/master/doc/sonic-application-extension/sonic-application-extension-guide.md

Retrieves a list of strings related to the fast shutdown process.

```APIDOC
## GET /service/fast-shutdown/before

### Description
Retrieves a list of strings related to the fast shutdown process. This is similar to the information provided for warm-shutdown.

### Method
GET

### Endpoint
/service/fast-shutdown/before

### Response
#### Success Response (200)
- **before_shutdown_actions** (list of strings) - A list of actions or states related to the pre-shutdown phase.

#### Response Example
```json
{
  "before_shutdown_actions": [
    "saving_configuration",
    "flushing_arp_cache"
  ]
}
```
```

--------------------------------

### Example Usage of StorageDevices Class

Source: https://github.com/sonic-net/sonic/blob/master/doc/storagemond/storagemond-hld.md

Demonstrates how to instantiate the StorageDevices class and access the 'devices' attribute, which will contain instantiated utility objects for each discovered storage disk.

```python
# Assuming a device contains the following storage disks:
# root@sonic:~# ls /sys/block/
# loop0  loop1  loop2  loop3  loop4  loop5  loop6  loop7  **mmcblk0**  mmcblk0boot0  mmcblk0boot1  **sda**

# We would instantiate an object of the StorageDevices() class
# storage = StorageDevices()

# storage.devices would contain:
# {
#     'mmcblk0': <Emmcutil object>,
#     'sda': <SsdUtil object>
# }

# We then get static and dynamic information by leveraging the respective member function implementations of SsdUtil and EmmcUtil,
# as they both derive from SsdBase.
# We then leverage the following proposed STATE_DB schema to store and stream information about each of these disks.
```

--------------------------------

### GET /processes

Source: https://github.com/sonic-net/sonic/blob/master/doc/sonic-application-extension/sonic-application-extension-guide.md

Retrieves information about the processes running within the SONiC container.

```APIDOC
## GET /processes

### Description
Retrieves information about the processes running within the SONiC container.

### Method
GET

### Endpoint
/processes

### Parameters
#### Query Parameters
- **name** (string) - Optional - Filter processes by name.

### Response
#### Success Response (200)
- **processes** (list) - A list of process objects, each containing details about a running process.
  - **name** (string) - The name of the process.
  - **status** (string) - The current status of the process.
  - **pid** (integer) - The process ID.

#### Response Example
```json
{
  "processes": [
    {
      "name": "swss",
      "status": "running",
      "pid": 1234
    },
    {
      "name": "orchagent",
      "status": "running",
      "pid": 5678
    }
  ]
}
```
```

--------------------------------

### Example: Configure MUX Cable Operation Mode (CLI)

Source: https://github.com/sonic-net/sonic/blob/master/doc/dualtor/dualtor_active_standby_hld.md

Demonstrates setting the MUX cable to active mode for a specific port (Ethernet4) and shows potential outputs and their meanings. 'OK' indicates the state is already active, 'INPROGRESS' shows a transition, and RC 1 signifies failure.

```bash
eg: config muxcable mode active Ethernet4 [--json]
output case 1:
RC: 100
{
    “Ethernet4”: “OK”
}
Output case 2:
RC: 1
Output case 3:
RC: 100 
{
    “Ethernet4”: “INPROGRESS”
} 
```

--------------------------------

### GET /processes/[name]/reconciles

Source: https://github.com/sonic-net/sonic/blob/master/doc/sonic-application-extension/sonic-application-extension-guide.md

Checks if a specific process performs warm-boot reconciliation.

```APIDOC
## GET /processes/[name]/reconciles

### Description
Checks whether a specific process performs warm-boot reconciliation. The warmboot-finalizer service has to wait for this to complete.

### Method
GET

### Endpoint
/processes/[name]/reconciles

### Parameters
#### Path Parameters
- **name** (string) - Required - The name of the process to check.

### Response
#### Success Response (200)
- **reconciles** (boolean) - True if the process performs warm-boot reconciliation, False otherwise.

#### Response Example
```json
{
  "reconciles": true
}
```
```

--------------------------------

### Consutil Connection Examples via SSH

Source: https://github.com/sonic-net/sonic/blob/master/doc/console/SONiC-Console-Switch-High-Level-Design.md

Lists various SSH commands to connect to remote devices using 'consutil', demonstrating connections by line number, device name, and management IP, based on the `CONFIG_DB` setup.

```bash
ssh <user>@<host> consutil connect 1
ssh <user>@<host> consutil connect --devicename switch1
ssh <user>@<host> consutil connect --mgmtip 2001:db8::1
ssh <user>:1@<host>
ssh <user>@2001:db8::1
```

--------------------------------

### lm-sensors sensors.conf Configuration Example

Source: https://github.com/sonic-net/sonic/blob/master/doc/platform/brcm_pdk_pddf.md

This example demonstrates the configuration of the /etc/sensors.conf file for the lm-sensors package. It shows how to define the I2C bus, chip, and specific sensor readings, including labels and threshold values for temperature monitoring. The output from the 'sensors' command is also provided.

```text
sensors.conf:
     bus "i2c-3" "i2c-1-mux (chan_id 1)"
     chip "lm75-i2c-3-49"
     label temp1 "Temp Sensor"
     set temp1_max 60
     set temp1_max_hyst 56

 admin@sonic:~$ sensors
     lm75-i2c-3-49
     Adapter: i2c-1-mux (chan_id 1)
     Temp Sensor:        +27.0 C  (high = +60.0 C, hyst = +56.0 C)

```