Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ietf-netconf:copy-config failed. #1637

Open
rydy opened this issue Sep 5, 2024 · 3 comments
Open

ietf-netconf:copy-config failed. #1637

rydy opened this issue Sep 5, 2024 · 3 comments
Labels
is:bug Bug description.

Comments

@rydy
Copy link

rydy commented Sep 5, 2024

Hi,
I'm using version 2.2.19, Occasionally ‘copy-config’ fails, as shown in the following log:

INF]: SR: EV ORIGIN: "/ietf-netconf:edit-config" "rpc" ID 1 priority 0 for 1 subscribers published.
[INF]: SR: EV LISTEN: "/ietf-netconf:edit-config" "rpc" ID 1 priority 0 processing (remaining 1 subscribers).
[INF]: SR: No "running" datastore changes to apply.
[INF]: SR: EV LISTEN: "/ietf-netconf:edit-config" "rpc" ID 1 priority 0 success (remaining 0 subscribers).
[INF]: SR: EV ORIGIN: "/ietf-netconf:edit-config" "rpc" ID 1 priority 0 succeeded.
[DBG]: LN: Session 1: Sending message:

#92


[DBG]: LN: Session 1: Sending message:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="79"><ok/></rpc-reply>

[DBG]: LN: Session 1: Sending message:

##


[INF]: NP: Session 1: thread 1 event new RPC.
[DBG]: LN: Session 1: Received message:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="80"><copy-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><target><startup/></target><source><running/></source><with-defaults xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">report-all</with-defaults></copy-config></rpc>

[INF]: SR: EV ORIGIN: "/ietf-netconf:copy-config" "rpc" ID 1 priority 0 for 1 subscribers published.
[INF]: SR: EV LISTEN: "/ietf-netconf:copy-config" "rpc" ID 1 priority 0 processing (remaining 1 subscribers).
[ERR]: SR: JSON DS file: Opening "/opt/CDB/OM_DU/data/_3gpp_nr_nrm.startup.bck" failed (File exists).
[INF]: SR: EV LISTEN: "/ietf-netconf:copy-config" "rpc" ID 1 priority 0 fail (remaining 1 subscribers).
[WRN]: SR: EV ORIGIN: "/ietf-netconf:copy-config" "rpc" ID 1 priority 0 failed (System function call failed).
[ERR]: SR: User callback failed.
[ERR]: NP: Failed to send an RPC (User callback failed).
[DBG]: LN: Session 1: Sending message:

#560


[DBG]: LN: Session 1: Sending message:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="80"><rpc-error><error-type>application</error-type><error-tag>operation-failed</error-tag><error-severity>error</error-severity><error-message xml:lang="en">JSON DS file: Opening "/opt/CDB/OM_DU/data/_3gpp_nr_nrm.startup.bck" failed (File exists).</error-message></rpc-error><rpc-error><error-type>application</error-type><error-tag>operation-failed</error-tag><error-severity>error</error-severity><error-message xml:lang="en">User callback failed.</error-message></rpc-error></rpc-reply>

[DBG]: LN: Session 1: Sending message:

##

I manually removed _3gpp_nr_nrm.startup.bck to solve the problem. Can I add delete handling in the following code?

ds_json.c/srpds_json_store_
        /* create backup file with same permissions (not owner/group because it may be different and this process
         * not has permissions to use that owner/group) */
        if ((fd = srpjson_open(srpds_name, bck_path, O_WRONLY | O_CREAT | O_EXCL, st.st_mode)) == -1) {
            srplg_log_errinfo(&err_info, srpds_name, NULL, SR_ERR_SYS, "Opening \"%s\" failed (%s).", bck_path,
                    strerror(errno));
            goto cleanup;
        }
        backup = 1;

thanks.

@michalvasko
Copy link
Member

If you look into the code, backup is a flag that ensures the file is removed before the function returns. So I do not understand how can the file remain unless the previous store was interrupted by a crash and was then not recovered for some reason.

@michalvasko michalvasko added the is:bug Bug description. label Sep 5, 2024
@rydy
Copy link
Author

rydy commented Sep 5, 2024

If you look into the code, backup is a flag that ensures the file is removed before the function returns. So I do not understand how can the file remain unless the previous store was interrupted by a crash and was then not recovered for some reason.

I got it, will you provide this fix commit?

@michalvasko
Copy link
Member

michalvasko commented Sep 5, 2024

It already is in the version you are using, I have not noticed any differences. So you should ideally provide more information so I can reproduce it and fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
is:bug Bug description.
Projects
None yet
Development

No branches or pull requests

2 participants