Terminating Another NETCONF Session
A client application’s attempt to lock the candidate configuration can fail because another user or application already holds the lock, as mentioned in Locking the Candidate Configuration. In this case, the NETCONF server returns an error message that includes the username and process ID (PID) for the entity that holds the existing lock:
<rpc-reply xmlns="URN” xmlns:junos=”URL”>
<rpc-error>
<error-severity>error</error-severity>
<error-message>
configuration database locked by:
user terminal (pid PID) on since YYYY-MM-DD hh:mm:ss TZ, idle hh:mm:ss
exclusive
</error-message>
</rpc-error>
</rpc-reply>
]]>]]>
If the client application has maintenance permission, it can end the session that holds the lock by emitting the <kill-session> and <session-id> tag elements in an <rpc> tag element. The <session-id> tag element specifies the process ID (PID) obtained from the error message:
<rpc>
<kill-session>
<session-id>PID</session-id>
</kill-session>
</rpc>
]]>]]>
The NETCONF server confirms that it has terminated the other session by returning the <ok/> tag in the <rpc-reply> tag element:
<rpc-reply xmlns="URN" xmlns:sdx="URL”>
<ok/>
</rpc-reply>
]]>]]>
We recommend that the application include logic for determining whether it is appropriate to terminate another session, based on factors such as the identity of the user or application that holds the lock, or the length of idle time.
When a session is terminated, the NETCONF server that is servicing the session rolls back all uncommitted changes that have been made during the session.
The following example shows how to terminate a session:
Client Application | NETCONF Server |
|---|---|
<rpc> |
|
| <rpc-reply xmlns=”URN”
xmlns:sdx=”URL” > |