dockcheck icon indicating copy to clipboard operation
dockcheck copied to clipboard

ConPath does not contain a valid path from com.docker.compose.project.working_dir

Open tarchive opened this issue 2 years ago • 4 comments

PhotonOS 4.0

root@photon [ ~/dockcheck ]# ./dockcheck.sh
. . . . . . . . . . . . . . . . . . . .
Containers on latest version:
Portainer
Influxdb

Containers with errors, wont get updated:

Containers with updates available:
1) Grafana
2) Prometheus

Choose what containers to update.
Enter number(s) separated by comma, [a] for all - [q] to quit: 1

Updating containers:
Grafana

./dockcheck.sh: line 239: cd: /data/compose/76: No such file or directory
Path error - skipping Grafana
All done!
Would you like to prune dangling images? y/[n]: n
root@photon [ ~/dockcheck ]# ls -l /
total 48
lrwxrwxrwx   1 root root     7 Feb 24  2021 bin -> usr/bin
drwxr-xr-x   4 root root  4096 Jul  9 07:25 boot
drwxr-xr-x  17 root root  3140 Aug  9 22:20 dev
drwxr-xr-x  51 root root  4096 Aug  7 13:07 etc
drwxr-xr-x   2 root root  4096 Feb 24  2021 home
lrwxrwxrwx   1 root root     7 Feb 24  2021 lib -> usr/lib
lrwxrwxrwx   1 root root     7 Feb 24  2021 lib64 -> usr/lib
drwx------   2 root root 16384 Apr 27 14:37 lost+found
lrwxrwxrwx   1 root root     9 Feb 24  2021 media -> run/media
drwxr-xr-x   9 root root  4096 Aug  5 15:03 mnt
drwx--x--x   3 root root  4096 Apr 27 15:39 opt
dr-xr-xr-x 803 root root     0 Aug  9 22:19 proc
drwxr-x---   9 root root  4096 Aug  9 17:41 root
drwxr-xr-x  21 root root   720 Aug 10 06:43 run
lrwxrwxrwx   1 root root     8 Feb 24  2021 sbin -> usr/sbin
lrwxrwxrwx   1 root root     7 Feb 24  2021 srv -> var/srv
dr-xr-xr-x  11 root root     0 Aug  9 22:19 sys
drwxrwxrwt  11 root root   220 Aug 10 13:06 tmp
drwxr-xr-x  10 root root  4096 Apr 27 14:37 usr
drwxr-xr-x  12 root root  4096 Apr 27 14:38 var

As you can see there is no /data/compose/76 directory which is what was stored in ConPath from docker inspect "Grafana" --format '{{ index .Config.Labels "com.docker.compose.project.working_dir" }}' Possibly caused because container was created using a Portianer stack?

root@photon [ ~/dockcheck ]# docker inspect "Grafana" --format '{{ index .Config.Labels "com.docker.compose.project.working_dir" }}'
/data/compose/76

tarchive avatar Aug 10 '23 17:08 tarchive

Yeah I'm sorry but ./dockcheck.sh: line 239: cd: /data/compose/76: No such file or directory surely seems to match the layout Portainer uses for their stacks.

I've got another issue open that is due to how Portainer handles things (from what I can tell). I should really spin up a test machine with Portainer stacks and see what I could dig up.. Just havnt got to it. Sorry I'm of no assistance right now - other than narrowing it down to how my script handles things dosnt work out with how portainer does stacks.

mag37 avatar Aug 10 '23 17:08 mag37

Thanks for the quick reply. It's not a rush item for me so take your time. I was hoping it was an easy issue to spot and I have not actually dug into it myself either. I'm busy with other things at the moment so I would have to come back to this later anyhow.

For now your script still provides me an output of which containers are out of date which is very helpful for managing updates.

tarchive avatar Aug 10 '23 18:08 tarchive

Apparently they are in /var/lib/docker/volumes/portainer_data/_data/compose

root@photon [ ~ ]# find /var/lib/docker/volumes/portainer_data/_data/compose/ -name docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/52/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/80/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/72/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/68/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/71/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/53/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/75/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/69/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/17/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/44/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/51/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/43/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/67/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/78/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/57/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/63/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/76/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/18/docker-compose.yml
/var/lib/docker/volumes/portainer_data/_data/compose/73/docker-compose.yml

Which makes sense once i look backed at the command used to create portainer docker run -d -p 9000:9000 --name Portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce

tarchive avatar Aug 10 '23 18:08 tarchive

Thank you for keep digging. Is the rest of that containers data in the same path then, if you use relative path for bind volumes? Like you'd have ./data/:/data in the compose/stack.

Seems like I should do some testing with this and see if I can write a function to handle portainer containers if it's not too messed up.

mag37 avatar Aug 11 '23 07:08 mag37