ERROR cannot unmarshal common settings: unexpected end of JSON input #251
-
this is openwrt log:
this is my json: {
"settings": [
{
"provider": "porkbun",
"domain": "yefenghu.***",
"host": "@",
"api_key": "***",
"secret_api_key": "***",
"ip_version": "ipv4"
}
]
} |
Beta Was this translation helpful? Give feedback.
Replies: 12 comments 10 replies
-
Make sure you have bind mounted the file correctly. Usually Also maybe the problem comes from Windows line endings |
Beta Was this translation helpful? Give feedback.
-
@qdm12 I started getting this after the most recent update. Shows I am running version latest built on 2021-10-15T14:43:47Z (commit 14cd7b0). My json shows it is valid at https://jsonlint.com. I get the same error if I change config.json to {} rather than no setting found. Permissions on config.json are 777 for debugging purposes. I ran dos2unix on config.json to ensure no Windows characters are in the file. I also added LOG_LEVEL=debug, but get no additional information. I am not able to connect to the container to verify it sees the file as the container does not stay running, but my config has not changed. logs
docker-compose
config.json
|
Beta Was this translation helpful? Give feedback.
-
check your config.json is in /root/data/ |
Beta Was this translation helpful? Give feedback.
-
@qdm12 Oops. I added that as another step to troubleshoot today. Was thinking it was a way to tell the container where to find the file since it does not seem to be finding it. I have removed it. That was not there previously and does not work without it. I am guessing since I do not get no config found with only {} in the config.json file either the container does not see the file or the container is no longer looking in the same spot. @yefenghu There is no way for me to validate it since the container does not stay running. The docker-compose says the data dir is /updater/data, not /root/data. Did it change? Maybe that is the issue. |
Beta Was this translation helpful? Give feedback.
-
So if I change my volume to - "${docker}/ddns-updater:/root/data" I do get "WARN Found no setting to update record". Seems like /updater/data is the right location and it is seeing the file, but is not reading it properly even with just {} in it. I think permissions are ruled out since they are 777. Not sure what else it could be at this point. |
Beta Was this translation helpful? Give feedback.
-
It is not empty. I only did that temporarily to rule out a json issue in my config file. It is what is above and the Docker .env file |
Beta Was this translation helpful? Give feedback.
-
Actually, the program does write an empty JSON file I pushed an image |
Beta Was this translation helpful? Give feedback.
-
Log looks the same other than no version listed. I have env var LOG_LEVEL=debug.
|
Beta Was this translation helpful? Give feedback.
-
That did not change the logging level either. |
Beta Was this translation helpful? Give feedback.
-
Here is the docker-compose I used.
|
Beta Was this translation helpful? Give feedback.
-
I can't explain it, but this morning I removed the container and both images, rebooted, and reran docker-compose up and it is working. I had tried removing the container and image yesterday, so It was either the reboot or the combination of the two. I was obviously running the new image. Seems like something between docker or that image and the file system, some type of cache maybe. I've got 50+ other containers running without issue. Very strange. Appreciate your help. |
Beta Was this translation helpful? Give feedback.
-
this is my log:
175.11.. is correct , 240e:5a*:0:114:114:114:102 i do not konw what it from,need to solve it ? |
Beta Was this translation helpful? Give feedback.
I can't explain it, but this morning I removed the container and both images, rebooted, and reran docker-compose up and it is working. I had tried removing the container and image yesterday, so It was either the reboot or the combination of the two. I was obviously running the new image. Seems like something between docker or that image and the file system, some type of cache maybe. I've got 50+ other containers running without issue. Very strange. Appreciate your help.