fix defaultPrefix to honor a root ?

[c0b]

the defaultPrefix in libnetwork not honoring any specified root, when I have given root for graphdriver? but libnetwork still creates /var/lib/docker can we avoid this?

and this could be a problem when I ran different docker daemon with different driver / root flags simultaneously?

➸ sudo find /var/lib/docker/ -ls
 93174    0 drw-------   3 root     root           60 Nov  8 18:14 /var/lib/docker/
 93175    0 drw-------   3 root     root           60 Nov  8 18:14 /var/lib/docker/network
 93176    0 drw-------   2 root     root           60 Nov  8 21:41 /var/lib/docker/network/files
  1200    0 srw-------   1 root     root            0 Nov  8 21:41 /var/lib/docker/network/files/d10945c8a9706cc93c1b8074f20092d959a0b7d0a64b7cee1058bcdb91fd5c6e.sock

# part of docker daemon --help
  --exec-root=/var/run/docker          Root of the Docker execdriver
  -g, --graph=/var/lib/docker          Root of the Docker runtime

[thaJeztah]

I think #742 is fixing this (but haven't looked at it in detail 😄)

[c0b]

looks like so; could @calavera do a recursive search after your change and confirm there is no more such constant default prefix? then you can add "fix #747" in your commit msg

git grep -r '"/var/lib/docker"'

[calavera]

There are no more hard coded paths, afaik.

[tianon]

This is probably the more appropriate place to have posted moby/moby#18508 (comment):

This is a massive pain if one is dealing with a read-only / filesystem where /var/lib/docker cannot be created (and thus --graph is used to give Docker a different location to store files in). 😢

[tianon]

This will also have to contend with UNIX_PATH_MAX, but I think that's probably more of a documentation issue than a code issue.

(ie, the full length to a unix socket cannot exceed UNIX_PATH_MAX which is usually defined as 108; otherwise we get errors like Error starting daemon: Error initializing network controller: error obtaining controller instance: listen unix /...../files/fba09913080895f5ec61a98ab04f6c31408e4ecae4f397ccf69916ee2bb79d62.sock: bind: invalid argument)

[tianon]

In that context, having .../network/files/... be required as part of this path is kind of painful also -- it's really easy to get to 108+ when the basename is at least 70 (abcdef...890.sock) and .../network/files/... is implied. 😢

Is this directory used for anything other than UNIX sockets? Could they live under /run like containerd and other daemons use? (It'd still be good to have a daemon argument for controlling their location somehow, but at least then the base could be something shorter like /run/libnetwork instead of /var/lib/docker/network/files or /mnt/some-new-drive/var/lib/docker/network/files.)

[mavenugo]

@tianon thanks for the feedback. we are addressing this issue & lets target RC5 to have this resolved.

[mavenugo]

@tianon @thaJeztah there are a couple of issues that we are trying to address with the location. But for this .sock file especially, we could just go with your simple suggestion of moving the file under /run/libnetwork/. It definitely need not be under /var/lib/xxxx.
I will make that change now.

[GordonTheTurtle]

@c0b It has been detected that this issue has not received any activity in over 6 months. Can you please let us know if it is still relevant:

• For a bug: do you still experience the issue with the latest version?
• For a feature request: was your request appropriately answered in a later version?

Thank you!
This issue will be automatically closed in 1 week unless it is commented on.
For more information please refer to #1926