blob: 3f1cc22f2233b3db2e48d12a8c80801a7d912695 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
<html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta http-equiv="Content-Language" content="en" />
<title>s6: the s6-fdholder-transferdumpc program</title>
<meta name="Description" content="s6: the s6-fdholder-transferdumpc program" />
<meta name="Keywords" content="s6 s6-fdholder fd-holding fd-holder fd dump transfer unix socket activation" />
<!-- <link rel="stylesheet" type="text/css" href="//skarnet.org/default.css" /> -->
</head>
<body>
<p>
<a href="index.html">s6</a><br />
<a href="//skarnet.org/software/">Software</a><br />
<a href="//skarnet.org/">skarnet.org</a>
</p>
<h1> The <tt>s6-fdholder-transferdumpc</tt> program </h1>
<p>
<tt>s6-fdholder-transferdumpc</tt> talks to two
<a href="s6-fdholderd.html">fd-holding daemons</a>: the source of the
transfer on its
standard input, and the destination of the transfer on its standard output,
both being
open Unix domain sockets. It retrieves the entire storage state of
the source daemon and dumps it into the destination daemon.
</p>
<h2> Interface </h2>
<pre>
s6-fdholder-transferdumpc [ -t <em>timeoutfrom</em> ] [ -T timeoutto ]
</pre>
<ul>
<li> s6-fdholder-transferdumpc expects to talk to a listening
<a href="s6-fdholderd.html">s6-fdholderd</a> program on its descriptor 0 and
to another one on its descriptor 1. </li>
<li> It gets the entire set of file descriptors from the first
server, with their identifiers and possibly expiration dates. </li>
<li> It stores that set into the second server. The set is
<em>added</em> to the second server, which keeps the descriptors
it was already holding. </li>
<li> It then exits 0, or 1 if a server returned an error. </li>
</ul>
<h2> Options </h2>
<ul>
<li> <tt>-t <em>timeoutfrom</em></tt> : if the set-retrieving
operation cannot be processed in <em>timeoutfrom</em> milliseconds, then
fail with an error message.
Communications with the server should be near-instant, so this option is
only here to protect users against programming errors. </li>
<li> <tt>-T <em>timeoutto</em></tt> : same thing with the
set-storing operation. </li>
</ul>
<h2> Notes </h2>
<ul>
<li> s6-fdholder-transferdumpc is the "internal" version of
<a href="s6-fdholder-transferdump.html">s6-fdholder-transferdump</a>. It simply
expects to be run with file descriptors already open to both
servers; <a href="s6-fdholder-transferdump.html">s6-fdholder-transferdump</a>
takes care of all the plumbing. </li>
<li> The error messages for the s6-fdholder suite are explained
<a href="s6-fdholder-errorcodes.html">here</a>. </li>
<li> Dumping the entire state of <a href="s6-fdholderd.html">s6-fdholderd</a>
requires special authorizations. Make sure the s6-fdholderd instances are
<a href="s6-fdholderd.html#configuration">configured</a> to accept
dump-getting and dump-setting requests from your client. </li>
<li> A typical use case of
<a href="s6-fdholder-transferdump.html">s6-fdholder-transferdump</a> and
s6-fdholder-transferdumpc is when the main fd-holding daemon needs to
upgrade, or restart for some reason. Transferring the file descriptors
into another, temporary fd-holding daemon instance allows it to
restart without losing the descriptors. </li>
</ul>
</body>
</html>
|
