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.

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

Binding socket to the same port twice does not fail #1310

Closed
Razz4780 opened this issue Apr 17, 2023 · 3 comments
Closed

Binding socket to the same port twice does not fail #1310

Razz4780 opened this issue Apr 17, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@Razz4780
Copy link
Contributor

Bug Description

A process with injected mirrord layer is able to bind a socket to the same port twice. Such attempt fails without mirrord with OS error EADDRINUSE). Minimal example:

use std::net::UdpSocket;

fn main() {
    let _socket_1 = UdpSocket::bind("0.0.0.0:5555").unwrap();
    let err = UdpSocket::bind("0.0.0.0:5555").unwrap_err();
    eprintln!("{:?}", err);
}

This program fails when run with mirrord:

thread 'main' panicked at 'called `Result::unwrap_err()` on an `Ok` value: UdpSocket { addr: 0.0.0.0:5555, fd: 12 }', src/main.rs:5:47

Steps to Reproduce

  1. Prepare a binary from the provided example.
  2. Prepare a local cluster.
  3. Deploy a py-serv app from the testing guide.
  4. Run the binary with mirrord and the deployed app as a target.

Backtrace

No response

Relevant Logs

No response

Your operating system and version

Linux 5.19.0-38-generic #39~22.04.1-Ubuntu x86_64

Local process

ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=59fec39d65f671e16fbac571b1aa031829fba964, for GNU/Linux 3.2.0, with debug_info, not stripped

Local process version

No response

Additional Info

No response

@Razz4780 Razz4780 added the bug Something isn't working label Apr 17, 2023
@aviramha
Copy link
Member

aviramha commented Apr 17, 2023

This is because of #1124 that we decided to do as temp fix and should be resolved with #1123
I think we can track it in #1123 ?

@Razz4780
Copy link
Contributor Author

This is because of #1124 that we decided to do as temp fix and should be resolved with #1123 I think we can track it in #1123 ?

Sure, should've checked the existing issues

@Razz4780 Razz4780 closed this as not planned Won't fix, can't repro, duplicate, stale Apr 17, 2023
@aviramha
Copy link
Member

No problem! Always good to have more details ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants