Unable to close the configuration: UnlockError on J3400

[asyncnomi]

Hello,
I'm encountering the exact same issue as: Issue 578 on the EX3400-48p as well
The issue only occurs when requesting a commit, either a commit confirmed or a commit.

The exact error return is the same:
FAILED! => {"changed": false, "msg": "Unable to close the configuration: UnlockError"}

The thing is despite the changed: false, the commit is actually apply. It just failed to remove the lock.

I can confirm that:

• No user has an exclusive lock on the configuration.
• No user made changes to the shared configuration database but has not yet committed the changes.
• The user executing the Junos PyEZ code have permissions to configure the device (it is the root account for testing).

Other operation including diff, commit that only apply the unconfirmed one (by running a commit check), does release the lock without any issue.
I'm using Juniper.device v1.0.8

I'm running the exact same playbook on a mix EX4600/EX4300 4-members stack without any issues, It only seems to occurs on EX3400.

Thanks

Here are my ansible tasks:

- name: Diff
  juniper.device.config:
    host: "{{ ansible_host }}"
    port: 830
    template: "{{ template_path + '/config.conf' }}"
    vars: "{{ vars }}"
    load: update
    check: true
    commit: false
    diff: true
    timeout: 30
  register: results
  vars:
    ansible_command_timeout: 120
  tags:
    - diff

- name: display diff result
  ansible.builtin.debug:
    var: results.diff_lines
  when: results.diff_lines is defined
  tags:
    - diff
  
- name: Diff No modification
  ansible.builtin.debug:
    var: results.msg
  when: results.diff_lines is not defined
  tags:
    - diff

- name: Commit confirmed
  juniper.device.config:
    host: "{{ ansible_host }}"
    port: 830
    template: "{{ template_path + '/config.conf' }}"
    vars: "{{ vars }}"
    load: update
    check: false
    commit: true
    diff: false
    confirmed: 5
    timeout: 30
  register: results
  vars:
    ansible_command_timeout: 120
  tags:
    - commit_confirmed

- name: display commit confirmed result
  ansible.builtin.debug:
    var: results
  tags:
    - commit_confirmed

- name: Commit
  juniper.device.config:
    host: "{{ ansible_host }}"
    port: 830
    check: true
    commit: false
    diff: false
    timeout: 30
  register: results
  vars:
    ansible_command_timeout: 120
  tags:
    - commit

- name: display commit result
  ansible.builtin.debug:
    var: results
  tags:
    - commit

- name: Commit force
  juniper.device.config:
    host: "{{ ansible_host }}"
    port: 830
    template: "{{ template_path + '/config.conf' }}"
    vars: "{{ vars }}"
    load: update
    check: true
    commit: true
    diff: false
    timeout: 30
    check_commit_wait: 3
  register: results
  vars:
    ansible_command_timeout: 120
  tags:
    - commit_force

- name: display commit result
  ansible.builtin.debug:
    var: results
  tags:
    - commit_force

[tcpdump1]

Seeing the same issue on SRX345, exact same behaviour, no configuration locks but it still displays the Unlock Error.

After much testing, I managed to fix this by increasing timeout to 2 mins, the default timeout is 30 seconds, and if the timeout is exceeded, it throws out the Unlock Error.

    - name: Load replace from a file.
      juniper.device.config:
        config_mode: 'exclusive'
        load: 'replace'
        timeout: 120 <=== After increasing this, it worked
        src: "/tmp/full_config.conf"
        commit: true
      register: junos_result

[chidanandpujar]

Hi @asyncnomi,
As per @tcpdump1 suggestion, could you please increase the timeout and verify and share the results.

Thanks
Chidanand

[asyncnomi]

Hi @asyncnomi,
As per @tcpdump1 suggestion, could you please increase the timeout and verify and share the results.

Thanks
Chidanand

Hello,

I confirm that increasing the timeout to severals minutes (even if the time needed to commit the conf is way below that point) fixes the issue.
Thanks @tcpdump1 for the suggestion !

Sounds like a workaround more than a fix ? But that enough for my usage.

Thanks

[chidanandpujar]

Hi @asyncnomi,
As per @tcpdump1 suggestion, could you please increase the timeout and verify and share the results.
Thanks
Chidanand

Hello,

I confirm that increasing the timeout to severals minutes (even if the time needed to commit the conf is way below that point) fixes the issue. Thanks @tcpdump1 for the suggestion !

Sounds like a workaround more than a fix ? But that enough for my usage.

Thanks

Hi @asyncnomi
Thanks for the confirmation.

Thanks
Chidanand