canonical / lxd

Powerful system container and virtual machine manager
https://canonical.com/lxd
GNU Affero General Public License v3.0
4.38k stars 931 forks source link

Error: Common start logic: Load go-lxc struct: open /tmp/lxd_config_XXXXXXXX: no such file or directory #5650

Closed falstaff1288 closed 5 years ago

falstaff1288 commented 5 years ago

Required information

Issue description

The snap package for lxd was automatically updated to 3.12. Since then, I am getting the error reported above.

Steps to reproduce

Output example

location: none
metadata:
  class: task
  created_at: "2019-04-10T09:54:02.229220231-04:00"
  description: Starting container
  err: 'Common start logic: Load go-lxc struct: open /tmp/lxd_config_704842104: no
    such file or directory'
  id: 98296cf9-d885-448a-847a-845aa7ddd642
  location: none
  may_cancel: false
  metadata: null
  resources:
    containers:
    - /1.0/containers/centos7test
  status: Failure
  status_code: 400
  updated_at: "2019-04-10T09:54:02.229220231-04:00"
timestamp: "2019-04-10T09:54:02.234962403-04:00"
type: operation
stgraber commented 5 years ago

The reason for this is that you or some daemon/script on your system decided to cleanup /tmp on the host, removing the snap-specific temporary directory which is used by LXD.

Doing so breaks /tmp in the snap environment and prevents any temporary file from being created by LXD. This causes what you're seeing above as well as a large number of other issues.

There is no way to fix this while LXD is running and snapd doesn't make it easy to fix that even if you stop LXD entirely, the easiest way out of this is to reboot and then make sure you don't have something wipe anything that says snap in /tmp.

TommyLike commented 2 years ago

@stgraber Is there any way to move thoese config file into another folder which won't get cleaned?

stgraber commented 2 years ago

Those aren't config files, they are temporary copies of files being copied in and out of the container.

/tmp is by all definitions the correct location for this. Now if the user or a tool they're using goes and deletes files from the filesystem that they didn't themselves create, it's not too surprising that things may break.

brauner commented 2 years ago

Those aren't config files, they are temporary copies of files being copied in and out of the container.

/tmp is by all definitions the correct location for this. Now if the user or a tool they're using goes and deletes files from the filesystem that they didn't themselves create, it's not too surprising that things may break.

You can check journalctl whether systemd-tmpfiles-clean or similar has run. That would be a suspect.