Changes to global_config.json not persisting

This may be a boneheaded question, but when I make changes to my global_config.json, they disappear after restarting or rebooting.

What am I missing? Do those commands revert the code to the original docker build from the push?

I’m attempting to set up my GPS on a RAK831 and I think I need to specify where to write the tty files so that I can see if it’s connecting…

Hi, can you provide a bit more information, what’s that global_config.json that you are using?

What project are you running? Is that a file within the application container? If it’s inside the application, is the file inside a persistent volume? If not, runtime modifications will be lost on container restart. Thus need to either use a persistent volume, or use it part of your application (ie. making the modifications part of the application you deploy).

First off, thanks for the quick reply. The part of the global_config.json that I am looking at is here:

"gateway_conf": {
    "gateway_ID": "B827EBFFFE38A69E", 
    "description": "Residential Gateway off of 183 and Anderson Mill", 
    "gps_tty_path": "/dev/ttyAMA0", 
    "servers": [
            "serv_down_enabled": true, 
            "server_fallbacks": [
            "server_address": "", 
            "serv_gw_id": "qwipt_uno", 
            "serv_type": "ttn", 
            "serv_gw_key": "ttn-account-v2.MOgR2utXWRKLSJXKvaeP5ACrKy_WnzAOAPZCaIJKqTM9LHlz8FAlUoiEEkqZhnfcOb4PJNWYQdqtVaNhZp4LFg", 
            "serv_enabled": true
    "contact_email": "", 
    "fake_gps": false, 
    "stat_file": "loragwstat.json", 
    "logger": false, 
    "gps": true


I’m trying to resolve hundreds of these from the logs:
main 19:57:19 WARNING: [gps] read() returned value 0

…and I think it has to do with my gps_tty_path setting that I need to alter or add another…?

The project that I am running is exactly off of this tutorial:

It does use Docker (This is my first experience with Docker) and yes it the main application code was cloned from the above repo and then pushed up to my local machine.

Am I to assume that any time I restart or reboot it does so from the container that that pushed up the the repo I have with Balena? That certainly would answer the question.

Also, what is the difference between restart and reboot in laymans terms? I noticed that reboot takes longer, but other than that, I didn’t notice any difference.

Hi @Qwipt, first of all welcome to the balena community : )

Funny enough last week one of our teammates published 10 min video on setting up LoRa gateway:

Perhaps you’d find this video useful. This video and the base repo used are actually alternative guides to the one you linked:

In this guide I link, the setup is simplified as you could use the environment variables in balenaCloud dashboard instead of changing the config.json file directly. Let us know how it goes.

There is also a way to to edit config.json file directly. Then I think it’s simpler and more straightforward to handle it via balenaCloud dashboard. (As you guessed correctly, balena overwrites the config variables set outside the balena dashboard to keep a single source of authority on things.)

Finally, let me answer your question about restart vs reboot: Reboot does a power cycle in your device as the application services stopped first, then the balena supervisor is stopped and the device shuts down before it powers up again. Restart in the balenaCloud dashboard means restarting the application containers without a power cycle.

We explain this in our docs as well:

Hi there,

Just to follow on a bit from @gelbal’s post, I think there’s a bit of a misunderstanding. I believe you’re talking about a global_config.json file within the Docker service container that’s running on your device, correct?

If you make changes to data locally inside the service container (ie. in this case the global_config.json file), there’s no guarantee that this changes will persist across a reboot or a restart (in fact, I believe atm a reboot probably will persist them, but a restart probably won’t). This is because the container will be created from the pushed application image. If you want to be able to make changes that persist over reboots and restarts, you’re best off creating using persistent storage that will hold any changes that occur to files/data and be picked up over reboots/restarts. Note that pushing new applications will not invalidate persistent volumes and as such that data will stay safe. You can explicitly map filesystem paths to volumes in a docker-compose.yml file for multicontainer apps (or a MC app with a single service), else /data will be present in single-container apps.

There’s a section on persistent storage here.

Hope this helps!