Juju commands fail - Error unable to open /tmp/juju-store-lock-3635383939333230

2.9k Views Asked by At

I've got a little problem with Juju and I was windering if someone came accross it or know what it can be.

I'm using Juju 2.8.1-focal-amd64 in association with MAAS 2.8.1 (8567-g.c4825ca06) in order to deploy an Openstack cloud.

I've installed and run the Juju commands as the user root.

And when I enter a Juju command I got the following message : ERROR cannot acquire lock file to get the current controller name: unable to open /tmp/juju-store-lock-3635383939333230: permission denied

It first came when I try to bootstrap a controller :

09:30:56 INFO  juju.cmd supercommand.go:91 running juju [2.8.1 0 16439b3d1c528b7a0e019a16c2122ccfcf6aa41f gc go1.14.4]
09:30:56 DEBUG juju.cmd supercommand.go:92   args: []string{"/snap/juju/13324/bin/juju", "bootstrap", "--constraints", "tags=juju", "mymaas", "maas-controller", "--debug"}
09:30:56 DEBUG juju.cmd.juju.commands bootstrap.go:1153 authenticating with region "" and credential "anyuser" ()
09:30:56 DEBUG juju.cmd.juju.commands bootstrap.go:1281 provider attrs: map[]
09:30:57 INFO  cmd authkeys.go:114 Adding contents of "/root/.local/share/juju/ssh/juju_id_rsa.pub" to authorized-keys
09:30:57 INFO  cmd authkeys.go:114 Adding contents of "/root/.ssh/id_rsa.pub" to authorized-keys
09:30:57 DEBUG juju.cmd.juju.commands bootstrap.go:1340 preparing controller with config: map[agent-metadata-url: agent-stream:released apt-ftp-proxy: apt-http-proxy: apt-https-proxy: apt-mirror: apt-no-proxy: authorized-keys:ssh-rsa  juju-client-key
ssh-rsa key= root@infra01
 automatically-retry-hooks:true backup-dir: cloudinit-userdata: container-image-metadata-url: container-image-stream:released container-inherit-properties: container-networking-method: default-series:bionic default-space: development:false disable-network-management:false egress-subnets: enable-os-refresh-update:true enable-os-upgrade:true fan-config: firewall-mode:instance ftp-proxy: http-proxy: https-proxy: ignore-machine-addresses:false image-metadata-url: image-stream:released juju-ftp-proxy: juju-http-proxy: juju-https-proxy: juju-no-proxy:127.0.0.1,localhost,::1 logforward-enabled:false logging-config: lxd-snap-channel:latest/stable max-action-results-age:336h max-action-results-size:5G max-status-history-age:336h max-status-history-size:5G name:controller net-bond-reconfigure-delay:17 no-proxy:127.0.0.1,localhost,::1 provisioner-harvest-mode:destroyed proxy-ssh:false resource-tags: snap-http-proxy: snap-https-proxy: snap-store-assertions: snap-store-proxy: snap-store-proxy-url: ssl-hostname-verification:true test-mode:false transmit-vendor-metrics:true type:maas update-status-hook-interval:5m uuid:528fe789-5850-4ab6-831b-1d6370fb6512]
ERROR error reading current controller: cannot acquire lock file to get the current controller name: unable to open /tmp/juju-store-lock-3635383939333230: permission denied
09:30:57 DEBUG cmd supercommand.go:537 error stack:
permission denied
/build/snapcraft-juju-03af7d/parts/juju/src/vendor/github.com/juju/mutex/mutex_flock.go:92: unable to open /tmp/juju-store-lock-3635383939333230
/build/snapcraft-juju-03af7d/parts/juju/src/vendor/github.com/juju/mutex/mutex_flock.go:111:
/build/snapcraft-juju-03af7d/parts/juju/src/vendor/github.com/juju/mutex/mutex_flock.go:25:
/build/snapcraft-juju-03af7d/parts/juju/src/jujuclient/file.go:79:
/build/snapcraft-juju-03af7d/parts/juju/src/jujuclient/file.go:104: cannot acquire lock file to get the current controller name
/build/snapcraft-juju-03af7d/parts/juju/src/cmd/modelcmd/controller.go:129:
/build/snapcraft-juju-03af7d/parts/juju/src/cmd/juju/commands/bootstrap.go:655: error reading current controller

I've try to change the permissions on this file (with a chmod 777) but that doesn't work.

Thanks in advance :)

1

There are 1 best solutions below

0
On

This happens because Juju expects to use juju commands as the normal user and not as root. Removing the local files from /tmp/juju-store-lock* and trying again should fix this.

Incidentally, juju does try and chown the permissions of the lock file using the original user, but it seems this isn't always perfect.