Please sign your commits following these rules:
https://github.com/moby/moby/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:

$ git clone -b "move-var-run-to-run" [email protected]:wiktor-k/moby.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

I try not to ignore warnings as this builds "warning blindness" but I understand your reasoning. /run was introduced over 8 years ago.

Do you suggest closing this PR until this is discussed further?

Yes, I suggest closing PR, but maybe you can instead add a comment like this:

[Socket]
# If /var/run is implemented as a symlink to /run, you may specify ListenStream=/run/docker.sock instead.
ListenStream=/var/run/docker.sock

Note that there is no guarantee that /var/run is implemented as a symlink to /run, according to FHS 3.0: http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s13.html

maybe you can instead add a comment like this:

Okay, I think this still would be useful.

Note that there is no guarantee that /var/run is implemented as a symlink to /run

🤔 as far as I'm reading "It is valid to implement /var/run as a symlink to /run." I think they mean that /var/run can be implemented as symlink or in any other reasonable manner (hardlink? bind-mount?) not that they would point to two different places...

But my previous change would violate other rule that's also on that page:

Programs should not access both /var/run and /run directly, except to access /var/run/utmp.

That is accessing both /var/run and /run (as you mentioned in other places, like CLI or daemon).

Thanks for helping with this PR, I really appreciate it!

cc @andrewhsu @tianon

Are there common systemd-using systems that don't have the /var/run -> /run symlink in practice?

No AFAIK

Are there common systemd-using systems that don't have the /var/run -> /run symlink in practice?

That'd have to be an uncanny distro in my opinion. Systemd was released on 2010 and /run introduced in 2011 by the same author so I guess it's natural that the distro would follow the same path when adopting systemd.

Yeah, makes sense (and matches what I would expect) -- IMO this should probably go the other way in that case (default to /run, optionally with a comment explaining how to "fix" it for non-symlinking distros).

Okay, sounds reasonable. Adjusted the socket location and reversed comment's text. See if this looks better.

Codecov Report

Merging #39275 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #39275      +/-   ##
==========================================
- Coverage   37.05%   37.05%   -0.01%     
==========================================
  Files         612      612              
  Lines       45478    45478              
==========================================
- Hits        16853    16852       -1     
  Misses      26341    26341              
- Partials     2284     2285       +1

Note that this systemd unit file is not used in the deb/rpm packages; the packages use the unit file from https://github.com/docker/docker-ce-packaging/blob/master/systemd/docker.service

Also wondering; if we want to change the actual path; there's many locations in the codebase that look for /var/run/docker.sock (perhaps there's SELinux profiles that need to be updated). Note that containerd also still uses /var/run/...

@thaJeztah, what action would you suggest? I don't mind filing more PRs against these projects but if there is no consensus that it's a good idea then the work would be wasted...

Running Archlinux, and having installed docker 1:18.09.6-1, the docker.sock file is now created by the daemon in /run (which is not a symlink to / from /var/run on my machine for some reason - that is a faulty FS layout I suppose), but the client is still trying to connect to /var/run/docker.sock :-(

Edit: fixed by fixing the missing symlink between /run and /var/run.

@alcohol if that's a default setup of Archlinux, might be good to report that with the Archlinux maintainers. It will be a concern though if there's more systems in the wild that are missing the symlink.

@wiktor-k perhaps you could open an issue to track this, on which we can have a discussion on what changes would have to be made? Also thinking (e.g.) having a fallback in the Docker CLI to try both locations (first attempt /run/docker.sock, and fallback to /var/run/docker.sock). There are thousands of examples on the internet for using /var/run/docker.sock so we should make sure that those never break.

I do not think it is default. Was just my vps that was setup incorrectly. Most of my other Archlinux machines have the symlink.

if that's a default setup of Archlinux, might be good to report that with the Archlinux maintainers. It will be a concern though if there's more systems in the wild that are missing the symlink.

Just as @alcohol says it was probably a bug on one system. I'm using Arch as well and have correct symlinks in place. (Actually the warnings I saw that pushed me to open this PR was on Arch).

perhaps you could open an issue to track this, on which we can have a discussion on what changes would have to be made? Also thinking (e.g.) having a fallback in the Docker CLI to try both locations (first attempt /run/docker.sock, and fallback to /var/run/docker.sock). There are thousands of examples on the internet for using /var/run/docker.sock so we should make sure that those never break.

Good idea, which repo should I use? moby? or docker-ce-packaging?

Good idea, which repo should I use? moby? or docker-ce-packaging?

This repository would be fine; I expect changes will be needed in multiple repositories though (packaging, cli, as well as in this repository to change the default paths that are used, possibly SELinux profiles that need updating)