[問題] ncclient的問題

看板Python作者 (薇薇安安)時間1年前 (2022/04/29 16:12), 1年前編輯推噓2(2029)
留言31則, 4人參與, 1年前最新討論串1/1
hi,一直以來感謝版友熱心的回答 本人工作上要使用ncclient這個library,不知這裡有沒有人研究過 我的問題是,我現在要用ncclient建立一個 NETCONF 的session到遠端機器 以下是部份code: from ncclient import manager import unittest conn = manager.connect(host=***, username=***, password=***) with conn.locked(target='running'): conn.discard_changes() suite = unittest.TestSuite() suite.addTest(...) suite.addTest(...) unittest.TextTestRunner(verbosity=2).run(suite) 如果不用conn.locked (session不lock),則運行上沒有問題 有lock的話,在某個test中會出現以下錯誤信息: ncclient.operations,rpc.RPCError: Module "gold-storm" is DS-locked by 8738585 代表另有一個session已經lock住這個module,我必須要得到這個session的id並刪除之 然而,我用session_id的方法查到都是三個數字,比如:290 這個8738585不知是怎麼來的 先感謝各位願意看完,我要先休息了,描述得不夠清楚的地方請多包涵 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 108.254.89.199 (美國) ※ 文章網址: https://www.ptt.cc/bbs/Python/M.1651219928.A.C97.html

04/30 16:10, 1年前 , 1F
你應該先說一下 session_id 怎麼查的
04/30 16:10, 1F

04/30 23:51, 1年前 , 2F
樓上,conn.session_id
04/30 23:51, 2F

05/01 00:15, 1年前 , 3F
不知道為什麼你的 sessionId 都是三位數,這不太合理…
05/01 00:15, 3F

05/01 00:26, 1年前 , 4F
另外你 conn 拿到的 session 是當前的,不代表 locked 的也
05/01 00:26, 4F

05/01 00:26, 1年前 , 5F
是當前 client 的
05/01 00:26, 5F

05/01 00:26, 1年前 , 6F
Hsin, 你用session_id查到的是七位數嗎
05/01 00:26, 6F

05/01 00:28, 1年前 , 7F
他的位數沒有固定呀,我拿到的是四位數,但你看其他文件也
05/01 00:28, 7F

05/01 00:28, 1年前 , 8F
有超過七位數的狀況
05/01 00:28, 8F

05/01 00:29, 1年前 , 9F
我是想用conn.kill_session()把那個妨礙我的session刪
05/01 00:29, 9F

05/01 00:29, 1年前 , 10F
05/01 00:29, 10F

05/01 00:32, 1年前 , 11F
但我發現conn.kill_session(8738535) 不work
05/01 00:32, 11F

05/01 00:38, 1年前 , 12F
的確可以這樣殺,但原始碼裡說 kill_session() 只能殺 NETC
05/01 00:38, 12F

05/01 00:38, 1年前 , 13F
ONF session,不確定你拿到那個七位數的 session 是不是來
05/01 00:38, 13F

05/01 00:38, 1年前 , 14F
自 NON-NETCONF 的…
05/01 00:38, 14F

05/01 00:47, 1年前 , 15F
沒有其他錯誤訊息了嗎?有沒有試過去你的 host 上面查看 lo
05/01 00:47, 15F

05/01 00:47, 1年前 , 16F
g?
05/01 00:47, 16F

05/01 17:21, 1年前 , 17F
這是我在server端的log:https://controlc.com/8ad5af85
05/01 17:21, 17F

05/01 17:24, 1年前 , 18F
看到的session_id是368,請問有辦法判斷是否為
05/01 17:24, 18F

05/01 17:25, 1年前 , 19F
netconf session或non-netconf session在干擾嗎?
05/01 17:25, 19F

05/01 23:10, 1年前 , 20F
這我就不清楚了,如果是可以的話,我會先將 server 端重新
05/01 23:10, 20F

05/01 23:10, 1年前 , 21F
打開一次,紀錄當下的 session 再由 client 連線去排查
05/01 23:10, 21F

05/01 23:53, 1年前 , 22F
可是不是要先讓client和server連線才有session嗎?
05/01 23:53, 22F

05/02 06:23, 1年前 , 23F
如果只有一個測試也會錯嗎?再猜是不是 unittest 造
05/02 06:23, 23F

05/02 06:23, 1年前 , 24F
成的
05/02 06:23, 24F

05/02 09:56, 1年前 , 25F
只有一個也會錯
05/02 09:56, 25F

05/02 10:40, 1年前 , 26F
很像conn鎖住,unitest又創新session就無法存取了
05/02 10:40, 26F

05/02 10:42, 1年前 , 27F
log也有寫最早create的session鎖住所以後面模組無法
05/02 10:42, 27F

05/02 10:43, 1年前 , 28F
存取
05/02 10:43, 28F

05/03 14:54, 1年前 , 29F
The unittest did not create a new session and a new
05/03 14:54, 29F

05/03 14:55, 1年前 , 30F
lock. Below is how I list current active sessions
05/03 14:55, 30F

05/03 14:55, 1年前 , 31F
and locks:
05/03 14:55, 31F
NETCONF request (sent right after I lock the running datastore): <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> <datastores/> <sessions/> <statistics/> </netconf-state> NETCONF response: <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <netconf-state xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring"> <datastores> <datastore> <name>running</name> <locks> <global-lock> <locked-by-session>0</locked-by-session> <locked-time>1970-01-01T01:00:00+01:00</locked-time> </global-lock> </locks> </datastore> <datastore> <name>startup</name> </datastore> <datastore> <name>candidate</name> </datastore> </datastores> <sessions> <session> <session-id>390</session-id> <transport>netconf-ssh</transport> <username>root</username> <source-host>10.42.0.91</source-host> <login-time>2019-03-10T11:59:53+01:00</login-time> <in-rpcs>2</in-rpcs> <in-bad-rpcs>0</in-bad-rpcs> <out-rpc-errors>0</out-rpc-errors> <out-notifications>0</out-notifications> </session> </netconf-state> </data> ※ 編輯: VivianAnn (168.127.213.159 美國), 05/03/2022 14:58:54
文章代碼(AID): #1YQvtOoN (Python)