It seems you need to add bash-completion files for your new commands.

What about extending fdrecv to receive multiple fds?
We can add the implementation later, but we must design the CLI now in case.

What about extending fdrecv to receive multiple fds? We can add the implementation later, but we must design the CLI now in case.

How about this:

# Send multiple fds:
fdsend --block --fd 0,1,2 -b pipe_test

# Receive multiple fds:
fdrecv --fd 0,1,2 pipe_test --run cat  # 0 <-> 0, 1 <-> 1, 2 <-> 2 (full mapping)
fdrecv --fd 0,1   pipe_test --run cat  # 0 <-> 0, 1 <-> 1 (2 is ignored)
fdrecv --fd 0     pipe_test --run cat  # 0 <-> 0 (1 and 2 are ignored)

Also ensure that --fd, --stdin, --stdout, and --stderr are mutually exclusive,
and --stdin, --stdout, and --stderr accepting only the first single fd.

# Send multiple fds:
fdsend --block --fd 0,1,2 -b pipe_test

# Receive only first fd via --stdin, --stdout, or --stderr:
fdrecv --stdin pipe_test --run cat # 0 <-> stdin, ignore other fds.

What about supporting an abstract Unix socket (https://man7.org/linux/man-pages/man7/unix.7.html)?
It may help users pass a file descriptor between processes in different mount namespaces.

What about supporting an abstract Unix socket (https://man7.org/linux/man-pages/man7/unix.7.html)? It may help users pass a file descriptor between processes in different mount namespaces.

How about add a new command option for abstract unix socket?

fdsend --abstract --fd 1 sockspec
fdrecv --abstract --fd 1 sockspec run cat

or add an @ sign before sockspec to indicate it is a abstract unix socket:

fdsend --fd 1 @sockspec
fdrecv --fd 1 @sockspec run cat

Adding --abstract looks better for me.

Rationals:

--abstract option requires more type than @socket. It implies that passing an fd via an abstract socket requires care.

For abstract sockets, we cannot use inotify to detect the appearance of a listening socket. So the usability of these commands with --abstract differs from the commands without the option.

--abstract option allows users passing an fd via /run/user/$UID/fdsend/@fname :-)

In abstract and blocking mode, may be we can retry on ECONNREFUSED at intervals (like 500ms) until connect succeed, then send the file descriptor. Or other approaches?

I don't have any other idea than the polling approach.
For implementing private tools, watching the unix_bind() invocation with BPF can be a choice. However, I think it is not suitable for a tool in util-linux.

It would be nice if fdrecv could receive multiple fds from different sockets at once.
This is just an idea.

terminal A

fdsend --fd 0 sockA

terminal B

fdsend --pid 9999 --fd 1 sockB

terminal C

fdsend --pid 9999 --fd 32 sockC

trminal recv:

fdrecv -f 3 sockA -f 2 sockB -f 0 sockC --run CMD

This pull request sparks many ideas.

I find an alternative action --forward.
If --forward another-socket is given, fdrecv sends the received fds to another fdrecv instead of running the command specified with --run
So I think it is better to name the option verbs: --run or --forward.

(Added after submitting this comment)

Instead of adding --forward as a new action to fdrecv, we can implement fdfwd command specialized to fd forwarding. In this case, the option doesn't need a verb.

• Support receive multiple fds from different sockets at once.

Please note that I am currently focusing on stabilizing the new release. I will work on this PR later.

Review of the final state

Overall the idea is solid and the SCM_RIGHTS handling is correct. A few things
need attention before this can be merged.

Critical

Compilation error — ul_parse_pid_str_or_err called with wrong arity (fdsend.c)

ul_parse_pid_str_or_err(optarg, &opts.pid, NULL);

The actual signature in include/pidutils.h is:

extern void ul_parse_pid_str_or_err(char *pidstr, pid_t *pid_num, uint64_t *pfd_ino, int flags);

Missing the 4th flags argument. Should be:

ul_parse_pid_str_or_err(optarg, &opts.pid, NULL, 0);

fdrecv must use getopt_long()

The hand-rolled strcmp() option parser in fdrecv.c is a significant deviation
from every other util-linux tool. It's fragile, hard to extend, and it's already
caused fdrecv to be added to unsupported_programs in tools/get-options.sh
(which is a red flag).

The multi-socket syntax (-f N SOCKSPEC)... --run CMD is solvable with
getopt_long(). You can loop: call getopt_long(), when you hit -f grab
its required_argument, then consume argv[optind] as the SOCKSPEC (advancing
optind manually). --run becomes the sentinel that stops the option loop
and everything after it is the command — same pattern as env or chroot use.

This matters for maintainability: every new flag will require hand-coding all
interactions, -- handling is missing entirely, and is_option() misidentifies
filenames starting with - as options.

Security / Correctness

1. Socket directory created with 0755 (fdsend-common.c, ul_mkdir_p(dir, 0755)
   for /run/user/UID/fdsend/) — lets other users enumerate socket names.
   Should be 0700 for per-user directories.

2. Abstract sockets have no access control — path-based sockets get
   chmod(path, 0600), but abstract sockets have no filesystem-level
   permissions. Any process in the same network namespace can connect and
   send an fd to fdrecv. Worth documenting in the man page at minimum;
   consider SO_PEERCRED verification.

3. Abstract socket --blocking is an infinite busy-loop (fdsend-common.c) —
   retries connect() every 100ms forever, no timeout, no backoff, no max
   attempts. If the receiver never starts, the only exit is SIGINT. The man page
   for --blocking doesn't mention this differs from path-based sockets
   (which use inotify).

4. fdsend_wait_for_socket() initial timeout logic — poll_timeout_ms
   starts at 2000, then switches to -1 (infinite). The 2-second window seems
   arbitrary; inotify + infinite poll is sufficient from the start.

Code quality nits

• #include <err.h> in fdsend.c is unnecessary — c.h already provides
  err()/warn(). fdrecv.c doesn't include it, so this is inconsistent.

• strncpy(path, spec, size) in sockpath_from_spec() — prefer
  snprintf(path, size, "%s", spec) or xstrncpy() which are more idiomatic
  for util-linux.

• -a/--abstract positioning logic in fdrecv.c is subtle — the condition
  sockspec_idx < n_pairs (meaning "current pair doesn't have a sockspec yet")
  is non-obvious and deserves a comment.

• Signal handlers are set up per-socket inside fdrecv_accept_and_recv_fd()
  rather than once in main(). They're idempotent so it works, but it's
  cleaner to initialize once.

Man pages

• Both man pages lack an EXAMPLES section. For tools with non-trivial CLI
  syntax (especially fdrecv's multi-socket mode), concrete examples are
  essential. The PR description already has a good one — move it into the
  man pages.

• --blocking description says "Wait for the socket to appear before
  connecting" — this is only true for path-based sockets. For abstract sockets,
  it's a connect-retry loop. Users need to know.

Tests

• sleep 1 for synchronization between fdrecv and fdsend is race-prone on
  slow CI. Consider increasing or using a wait loop.

• No negative test cases (duplicate target fds, missing sockspec, invalid fd,
  abstract socket mode, --pidfd-getfd mode).