You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since updating to 4.3.0 (from 4.2.1), we've noticed an issue wherein the session log file is not written to until the remote connection is disconnected. This issue has only been observed on fortinet device types so far (due to our environment, though it may occur on other device types). In the past, we would tail the session log to monitor the read/write activity while executing network automation scripts since it was a "live" view of the device CLI, and allowed our engineers to watch for any unexpected activity or errors.
This issue has been reproduced on macOS 14.3, Ubuntu 22.04.3, and RHEL 7.9. Our current workaround has been to revert back to netmiko 4.2.1 for now.
Setup
Netmiko version
(Paste verbatim output from pip freeze | grep netmiko between quotes below)
netmiko==4.3.0
Netmiko device_type (if relevant to the issue)
(Paste device_type between quotes below)
fortinet
Steps to Reproduce the Issue
Send any batch of commands and follow the session log with `tail -f <PATH-TO-LOG>`
The text was updated successfully, but these errors were encountered:
cbuons
changed the title
Session log file is empty for fortinet type devices until the remote connection is disconnected
Session log file is empty for fortinet type devices until the remote connection is disconnected
Feb 2, 2024
cbuons
changed the title
Session log file is empty for fortinet type devices until the remote connection is disconnected
Session log file is empty for fortinet type devices while the remote connection is still active
Feb 2, 2024
Description of Issue/Question
Since updating to 4.3.0 (from 4.2.1), we've noticed an issue wherein the session log file is not written to until the remote connection is disconnected. This issue has only been observed on
fortinet
device types so far (due to our environment, though it may occur on other device types). In the past, we would tail the session log to monitor the read/write activity while executing network automation scripts since it was a "live" view of the device CLI, and allowed our engineers to watch for any unexpected activity or errors.This issue has been reproduced on macOS 14.3, Ubuntu 22.04.3, and RHEL 7.9. Our current workaround has been to revert back to netmiko 4.2.1 for now.
Setup
Netmiko version
(Paste verbatim output from
pip freeze | grep netmiko
between quotes below)Netmiko device_type (if relevant to the issue)
(Paste
device_type
between quotes below)Steps to Reproduce the Issue
The text was updated successfully, but these errors were encountered: