S6-FDHOLDER-TRANSFERDUMP(8)

📦 version 2.15.1.0, in nixpkgs unstable

💅 s6-fdholder-transferdump — the group-chat guide 💅

okay so bestie, this one's a real one. It's a page from the System Manager's Manual, and it's literally called s6-fdholder-transferdump — say that five times fast, I dare you. 🫶

✨ NAME ✨

s6-fdholder-transferdump — the way that this connects to two separate s6-fdholderd(8) daemons and transfers the entire content of the first one over to the second one. it's giving "moving day" energy, no cap. 📦✨

🌸 SYNOPSIS 🌸

s6-fdholder-transferdump [-t timeoutfrom:timeoutto] pathfrom pathto

like, that's the whole vibe. two paths, maybe a timeout, we're done. 🎀

🦋 DESCRIPTION 🦋

So here's what's actually happening, bestie, and it's honestly iconic:

s6-fdholder-transferdump connects to an s6-fdholderd(8) server process that's listening on pathfrom, and it grabs the whole entire set of file descriptors from that server — with their identifiers and (when it's relevant) their expiration dates. the whole thing. all of it. 💯

Then it connects to a different instance of s6-fdholderd(8) that's listening on pathto, and it stores that whole set of file descriptors in there. and listen — the set gets added to the second server, which means the second server keeps all the descriptors it was already holding. it's not a replacement situation, it's a "you get more friends" situation. 🫶🦋

⚠️ ok so important bit, don't skip this: dumping the entire state of s6-fdholderd(8) requires special authorizations. like, fr fr. make sure both s6-fdholderd(8) instances are configured to accept dump-getting and dump-setting requests from your client. if you need the details, go read s6-fdholderd(8). iykyk. 🔑

And the classic use case — the reason this tool even exists, honestly — is when your main fd-holding daemon needs to upgrade, or has to restart for some reason. transferring all the file descriptors into another temporary fd-holding daemon instance means it can restart without losing any of the descriptors. it's literally the "hold my stuff while i go do this" maneuver and it ate. 👑🔥

💅 OPTIONS 💅

  • -t timeoutfrom:timeoutto — if the operations can't be processed within timeoutfrom milliseconds (that's the connection to pathfrom) or timeoutto milliseconds (that's the connection to pathto), then it fails with an error message. and ngl, communications with the servers should be near-instant, so this option is only here to protect users against programming errors — like connecting to the wrong socket, for instance. 🙈 it's a safety net, not a lifestyle. 🎀

⭐ EXIT STATUS ⭐

  • 0 — Success. slay. 💖
  • 1 — the source server denied the operation. the meanings of the error messages are explained in s6-fdholder-error-codes(7). 😭
  • 2 — the destination server denied the operation. the meanings of the error messages are explained in s6-fdholder-error-codes(7). 😭😭
  • 100 — Wrong usage. bestie, check your arguments. 💀
  • 111 — System call failed — and this includes attempting to connect to a nonexistent socket, or one where no s6-fdholderd(8) daemon is listening. so like, is anyone even home? 🫠

🌈 SEE ALSO 🌈

This man page is ported from the authoritative documentation at: https://skarnet.org/software/s6/s6-fdholder-transferdump.html — go read the source, it's iconic. 📚✨

👑 AUTHORS 👑

  • Laurent Bercot
  • Alexis <flexibeast@gmail.com> (man page port)

and that's the whole page, bestie — no notes, periodt. 💅✨

🎀 cute little sign-off: this one's from the Debian corner of the world, dated September 29, 2021, and it lives at S6-FDHOLDER-TRANSFERDUMP(8) in the manual. mwah. 💖🦋🌸
📦 where this page comes from