Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Feature Request: support for listening on a unix socket. #933

Open
Allen-Webb opened this issue Jan 13, 2021 · 2 comments
Open

Feature Request: support for listening on a unix socket. #933

Allen-Webb opened this issue Jan 13, 2021 · 2 comments

Comments

@Allen-Webb
Copy link

I am trying to use sccache across network namespaces and realized it is hard coded to use the loopback. Would you all be willing to take patches for specifying a command line option or environmental variable that would accept a unix socket path to use for listening and connecting?

Lets call this option "-L", "--listen-on-path" it would need to be compiled out for windows, but there are already code that uses
#[cfg(not(windows))]

Alternatively to keep the flags the same across operating systems, it could just be set with an environment variable: SCCACHE_UNIX_LISTEN.
freebsd-git pushed a commit to freebsd/freebsd-ports that referenced this issue Feb 7, 2022
ports-mgmt/sccache-overlay: Use Unix sockets and fix Poudriere builds
060529b 
Poudriere builder jails seem to share one network namespace which
is problematic when building packages in parallel since sccache
binds to localhost:4226. This then leads to jails reusing the
sccache instance from other jails which is problematic and can
cause failures like

1/ missing files due to the filesystem separation:

  sccache: caused by: No such file or directory (os error 2)

2/ the sccache instance suddenly going away when a parallel build
finishes and Poudriere shuts down the jail and kills all of its
processes:

  sccache: error: failed to execute compile
  sccache: caused by: Failed to send data to or receive data from server
  sccache: caused by: Failed to read response header
  sccache: caused by: failed to fill whole buffer

To properly namespace sccache instances we can use Unix sockets.
There is a request [1] for adding support for Unix sockets
upstream but no code has been written for that AFAICT. This
commit hacks in support for them which should be just about ok
for our purposes.

[1] mozilla/sccache#933

Tested by:	jrm
camachat pushed a commit to camachat/freebsd-ports that referenced this issue Feb 9, 2022
@camachat
ports-mgmt/sccache-overlay: Use Unix sockets and fix Poudriere builds
6d4597d 
Poudriere builder jails seem to share one network namespace which
is problematic when building packages in parallel since sccache
binds to localhost:4226. This then leads to jails reusing the
sccache instance from other jails which is problematic and can
cause failures like

1/ missing files due to the filesystem separation:

  sccache: caused by: No such file or directory (os error 2)

2/ the sccache instance suddenly going away when a parallel build
finishes and Poudriere shuts down the jail and kills all of its
processes:

  sccache: error: failed to execute compile
  sccache: caused by: Failed to send data to or receive data from server
  sccache: caused by: Failed to read response header
  sccache: caused by: failed to fill whole buffer

To properly namespace sccache instances we can use Unix sockets.
There is a request [1] for adding support for Unix sockets
upstream but no code has been written for that AFAICT. This
commit hacks in support for them which should be just about ok
for our purposes.

[1] mozilla/sccache#933

Tested by:	jrm
5u623l20 pushed a commit to 5u623l20/freebsd-ports that referenced this issue Feb 13, 2022
ports-mgmt/sccache-overlay: Use Unix sockets and fix Poudriere builds
803ee7c 
Poudriere builder jails seem to share one network namespace which
is problematic when building packages in parallel since sccache
binds to localhost:4226. This then leads to jails reusing the
sccache instance from other jails which is problematic and can
cause failures like

1/ missing files due to the filesystem separation:

  sccache: caused by: No such file or directory (os error 2)

2/ the sccache instance suddenly going away when a parallel build
finishes and Poudriere shuts down the jail and kills all of its
processes:

  sccache: error: failed to execute compile
  sccache: caused by: Failed to send data to or receive data from server
  sccache: caused by: Failed to read response header
  sccache: caused by: failed to fill whole buffer

To properly namespace sccache instances we can use Unix sockets.
There is a request [1] for adding support for Unix sockets
upstream but no code has been written for that AFAICT. This
commit hacks in support for them which should be just about ok
for our purposes.

[1] mozilla/sccache#933

Tested by:	jrm
@vishwin
Copy link

vishwin commented Feb 19, 2023

Ping, this is important for environments where even the loopback interface is not available, or a situation like #1435 to name a couple use cases. In the FreeBSD ports/packages build case with our recommended tooling, those who want to cache compiler artefacts with this are unable to unless a directory containing the Unix socket is mounted to each jail (container), which do not have TCP/IP network access during build.

Trying to see where best to hook such support.

@drahnr
Copy link
Collaborator

drahnr commented Feb 21, 2023 •
edited

If the quality of the patch is sufficiently high, and the future is needed and the use-case is described in sufficient detail and is plausible, we commonly don't oppose. We'd like to see you around maintaining the added complexity if you're a heavy user though. Little beats extensive testing and day to day use.

That said, I'd be happy to review a PR :) - and sorry for the long delay.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@drahnr @vishwin @Allen-Webb