If you manually expose some host service via vsock by creating a DYNAMIC_PORT_RANGE socket (say we just go with the first available one, krun/socket/port-50000)…
muvm -it bash just doesn't work with a cryptic error:
Error: could not request launch to server: Failed to listen on vm socket
Because acquire_socket_lock() only checks for the existence of port-{port}.lock lockfiles it itself creates… and advisory locks on them… so it sees no .lock and tries to touch the occupied socket itself…
statx(AT_FDCWD, "/run/user/10000/krun/socket/port-50000.lock", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=0, ...}) = 0
openat(AT_FDCWD, "/run/user/10000/krun/socket/port-50000.lock", O_RDWR|O_CLOEXEC) = 3
flock(3, LOCK_EX|LOCK_NB) = 0
unlinkat(AT_FDCWD, "/run/user/10000/krun/socket/port-50000", 0) = -1 EBUSY (Device or resource busy)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 4
bind(4, {sa_family=AF_UNIX, sun_path="/run/user/10000/krun/socket/port-50000"}, 41) = -1 EADDRINUSE (Address already in use)
Having to do the lock for an external service is kind of a lot, and it's not documented— well, not like the entire feature is documented outside of PRs/issues :) buuut still.
If you manually expose some host service via vsock by creating a
DYNAMIC_PORT_RANGEsocket (say we just go with the first available one,krun/socket/port-50000)…muvm -it bashjust doesn't work with a cryptic error:Because
acquire_socket_lock()only checks for the existence ofport-{port}.locklockfiles it itself creates… and advisory locks on them… so it sees no.lockand tries to touch the occupied socket itself…Having to do the lock for an external service is kind of a lot, and it's not documented— well, not like the entire feature is documented outside of PRs/issues :) buuut still.