Watchtower: Environment Variables Removed After Update

[Veldkornet]

I'm using Watchtower n a Synology as specified here.

My problem is that after updating a container, all of the containers Environment Variables disappear and I have to go add all the variables back every week.
Is there any way to keep the variables during the update?

[woodpost]

happens to me, too. blows away all my variables, and replaces them with variables i don't recognize.

[stffabi]

This may be due to the fact, that the docker container used there is an older version.

The Docker version installed on Synology DSM 6/6.1 is older than the one supported by Watchtower. Until Synology updates Docker or Watchtower lowers the compatibility requirements, here are the steps to get it to work with an older version of Watchtower.

This problem should be fixed as soon #65 is fixed.

[desimaniac]

@Veldkornet @woodpost As a temporary measure, try specifying all the variables in the docker container creation command. It may retain the variables that way.

[Veldkornet]

Took a while, but I tested specifying everything with the creation command (volume, ports, variables).

Same problem though. Only the custom variables are lost, for example “TZ” to set the time zone (the ones that are standard for that docker image are of course put back). Everything else (volumes and ports) is fine afterwards.

[jamesla]

+1

[stffabi]

I would like to investigate this issue. Unfortunately I couldn't reproduce it so far on my end. Could you please post the following information.

• docker version output
• docker run command which causes the issue of loosing environment variables
• docker inspect your_container output before it's updated
• watchtower output with --debug flag during update.
• docker inspect your_container output after it has been updated by watchtower

That should help to track the things down.

[IskanderNovena]

Hmm, I wanted to try to get you a report today, but it is not failing me.
I've updated to DSM 6.2.
docker version gives me this:

# docker version
Client:
 Version:      17.05.0-ce
 API version:  1.29
 Go version:   go1.8
 Git commit:   e9bcf19-synology
 Built:        Wed Nov  1 17:00:28 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.05.0-ce
 API version:  1.29 (minimum version 1.12)
 Go version:   go1.8
 Git commit:   e9bcf19-synology
 Built:        Wed Nov  1 17:00:28 2017
 OS/Arch:      linux/amd64
 Experimental: false

[andrewjmetzger]

Chiming in here to simply ask: if on a newer Docker build, do we still need to symlink and create a scheduled task as outlined on the wiki?

Here's my docker version output:

Client:
 Version:      17.05.0-ce
 API version:  1.29
 Go version:   go1.8
 Git commit:   9f07f0e-synology
 Built:        Fri Dec 15 19:37:44 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.05.0-ce
 API version:  1.29 (minimum version 1.12)
 Go version:   go1.8
 Git commit:   9f07f0e-synology
 Built:        Fri Dec 15 19:37:44 2017
 OS/Arch:      linux/amd64
 Experimental: false

DSM Version: 6.1.4-15217 Update 5

[stffabi]

@andrewjmetzger I think this is still needed for synology. Unfortunately I don't own one to check it.

[andrewjmetzger]

@stffabi Thanks. 😄

Lots of things like synocommunity packages and some Docker containers need special treatment to run on the latest Synology NASes; hopefully my ds918+ should provide a good testing environment, if only for anecdotal evidence.

I should be able to test this over the next few days (most likely the upcoming weekend), and then report back. Having auto-updating containers would be great, as the Synology Docker GUI leaves much to be desired!

[florianfranconi]

Hello guys, I have the same problem with my synology? A solution?

[stffabi]

Unfortunately I'm unable to reproduce this issue and have never seen it. It seems like this is more or less an issue that gets only triggered on synology.

For investigation the points mentioned in this comment would be very helpy.

@FlorianFranconi on what DSM version are you currently?

[thewillwilson]

@stffabi I've got a spare synology if you need to test it on

[simskij]

If this still is an issue for anyone, feel free to let me know. Until then, this issue is closed as I dont have any synology device to try to reproduce it on myself.

[woodpost]

it's been working for me. it still populates containers with some weird env variables, but they don't seem to be doing any harm, and otherwise it works perfectly. cheers!

[Veldkornet]

This was working fine, but something in the last month or two has caused it to break again and the variables are being thrown away again.

[andrewjmetzger]

@Veldkornet

Synology recently updated their docker package, and it broke things again.

The solution, for now, is to uninstall the new docker package and manually install an older one, such as 17.05.0-0401.

You can download it here: https://archive.synology.com/download/Package/spk/Docker/17.05.0-0401/Docker-x64-17.05.0-0401.spk

Be sure to disable auto updates within Synology package center, but keep an eye out for another version when Synology updates the package again, just in case the newer version retains environment variables. It's never a great idea to run an outdated package for too long.

Hope this helps!

~ Andrew

[IvanShift]

Hello!
I have this issue. I use latest available version (Docker: 18.09.0-0513) but after updating container manually added Environment Variables are erased( How can I help you to find solution of this problem?

[andrewjmetzger]

Hi @IvanShift,

Synology recently updated their docker package, and it broke things again.

The solution, for now, is to uninstall the new docker package and manually install an older one.

You can download older releases of the Synology Docker package (as an SPK file) here: https://archive.synology.com/download/Package/spk/Docker/

The current version should be listed at the very bottom. Typically, the previous version will work as expected. You may have to recreate your environment variables, but this seems to vary from NAS to NAS.

Here's how to install a package from an SPK File:

1. With your SPK file downloaded, open up the Packager Center and click the “Manual Install” button.
2. Click “Browse” and, using the file browser, select the SPK file. Click “Next”.
3. You’ll be prompted to confirm the installation with a summary of the package with the option (checked by default) to run the package after installation.
4. Click "Apply" to install the package.

Be sure to disable auto updates within Synology package center, but keep an eye out for another version when Synology updates the package again, just in case the newer version retains environment variables. It's never a great idea to run an outdated package for too long.

Hope this helps! :)

[andrewjmetzger]

Another solution would be to use a management platform like Portainer and Stacks with Docker Compose.

Create a Stack for one or more containers and paste in a Compose version 2 configuration. Even if Watchtower removes the environment variables in the future, you can just re-deploy the affected stack to update it and restore the variables. If this becomes a frequent problem, though. I would still recommend temporarily downgrading your Docker package, so that Watchtower doesn't reset the container too often.

Edit: Updated the last paragraph for clarity.

[IvanShift]

Thank you!
But I can save and load config just clicking right mouse button on container and select import/export. It is really annoying to do it on several containers every week( Older version has the same problem (except v.17 but it's very old).

[simskij]

@all-contributors add @andrewjmetzger for bugs and examples.
As a sidenote, I don't really monitor closed issues. From what I can tell, using v17 remains the only solution for synergy users at this point.

[allcontributors[bot]]

@simskij

I've put up a pull request to add @andrewjmetzger! :tada: