dumpConfig failed: no such file or directory about gobrake HOT 5 CLOSED

To be honest, I'm not sure there is even a writeable /tmp/ directory -- this is a very locked down environment. I guess there must be, since the error isn't occurring very often?

Just curious, is it a container? It should occur every 10 minutes so I guess you just don't have /tmp.

I'm also curious what is in this new remote config feature, since I haven't seen anything that it would control.

The config feature is a new feature for Airbrake notifiers, that will (in the future), allow more control for customers to update and change configuration of their notifiers across their fleet, in one simple web interface, while still maintaining local config control for those who need it. This is the first part of that functionality. At the moment it's not very useful but we can already balance load on our servers without you making any changes to your setup.

Why does this file need to be written to disk at all?

Remote configuration changes notifier settings at the runtime. We dump the remote config on disk so that any changes that were made while the notifier was alive could be loaded as fast as possible without relying on network. Without it the notifier will start with default settings and then it'll make a HTTP request to read the remote config, and then it'll apply the real changes. This process could last 1-3 seconds (depends on your network). If we have a "local" remote config, during these 1-3 seconds your notifier will work as it should from the start.

I'm not sure what to suggest here. I guess if you run a container, this feature is indeed useless for you. Do you have experience with any other libraries or apps that require some persistency? As of now, I can see 4 options:

1. Do what other libraries do in this case (but first I need to know what they do)
2. You can create /tmp in your container/environment so that gobrake is happy
3. Keep the code but silence the logger so that you don't see the message
4. Delete this feature because it's not working as intended

The options are sorted by my preference. I would delete the code only when it's obvious there's no easy solution.

from gobrake.

Just curious, is it a container?

Yes, this application is running inside a container that intentionally has very little access.

We dump the remote config on disk so that any changes that were made while the notifier was alive could be loaded as fast as possible without relying on network. Without it the notifier will start with default settings and then it'll make a HTTP request to read the remote config, and then it'll apply the real changes. This process could last 1-3 seconds (depends on your network). If we have a "local" remote config, during these 1-3 seconds your notifier will work as it should from the start.

This makes sense. I just wish it were possible to explicitly turn off this persistence behavior, because the process will never restart inside the same container in our case.

I guess if you run a container, this feature is indeed useless for you.

Agreed, and given how common containerized environments are... I feel like this isn't going to be an uncommon thing. Other people might not lock their containers down quite as much, so it might "work" but have no effect for most people.

Do you have experience with any other libraries or apps that require some persistency?

Nope, no other libraries in this environment want any kind of local persistence.

As it is, this error is not a huge deal, just annoying, but I guess /tmp/ isn't a real thing on our container.

1. Do what other libraries do in this case (but first I need to know what they do)
2. You can create /tmp in your container/environment so that gobrake is happy
3. Keep the code but silence the logger so that you don't see the message
4. Delete this feature because it's not working as intended

The 5th option is to allow customers to explicitly disable persistence of remote config when they create the Notifier. The remote config feature can still operate normally, it would just never call dumpConfig.

from gobrake.

On GNU/Linux there's /var/lib/APPNAME:

/var/lib

Holds dynamic data libraries/files like the rpm/dpkg database and game scores. Furthermore, this hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users shouldn't ever need to modify files in /var/lib to configure a package's operation. State information is generally used to preserve the condition of an application (or a group of inter-related applications) between invocations and between different instances of the same application. An application (or a group of inter-related applications) use a subdirectory of /var/lib for their data. There is one subdirectory, /var/lib/misc, which is intended for state files that don't need a subdirectory; the other subdirectories should only be present if the application in question is included in the distribution. /var/lib/'name' is the location that must be used for all distribution packaging support. Different distributions may use different names, of course.

https://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/Linux-Filesystem-Hierarchy.html#var

Does that exist for you? Is it writable for your app?

from gobrake.

Linux filesystem hierarchies are not strictly standardized. Linux is just a kernel, unlike the BSDs and older Unix OSes. What distros do beyond using the kernel is up to them.

Some groups, like TLDP, attempt to retroactively document what most distros do with the filesystem, but it’s just a concept, not hard fact. NixOS is an example of a legitimate Linux distro that doesn’t attempt to follow any pre-existing filesystem hierarchies. Many distros vary from the “standard” to some degree.

For security reasons, the whole filesystem in our container is read only, since there is no need to write anything to disk within this container.

In my programming experience, it’s pretty unusual to have a library try to write anywhere on disk without the application requesting it or configuring it. Just providing an option not to persist anything to disk seems like the ideal solution here?

I also wonder what this code would do if someone were running a Go application on Windows (with its very different filesystem hierarchy).

Anyways, the available options seem pretty clear. I don’t know what the right choice is for Airbrake. We have no intention of making our containers writeable, but it’s possible we are literally your only customer with this environment.

from gobrake.

Thanks for the explanation, I understand what you are talking about. As for your idea, I don't want to add another option because it will clutter the config and add to the mess. Users will have to waste time reading documentation and configuring something they don't really care about. I think I will just delete this feature because it gets in the way. I will consult my team as well.

from gobrake.