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
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
|
<?xml version="1.0"?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
<refentry id="cockpit-spawn">
<refnamediv>
<refname>cockpit.js: Spawning Processes</refname>
<refpurpose>Spawning processes or scripts</refpurpose>
</refnamediv>
<refsynopsisdiv>
<para>This is the API for spawning a process and receiving its output, as well
as exit codes.</para>
</refsynopsisdiv>
<refsection id="cockpit-spawn-spawn">
<title>cockpit.spawn()</title>
<programlisting>
process = cockpit.spawn(args, [options])
</programlisting>
<para>Spawns a process on the system.</para>
<para>The <code>args</code> should be an array starting with the executable and
containing all the arguments to pass on the command line. If <code>args</code>
is a string then it is interpreted as an executable name. The optional
<code>options</code> argument is a javascript plain object and can contain
any of the following fields:
</para>
<variablelist>
<varlistentry>
<term><code>"binary"</code></term>
<listitem><para>If set to <code>true</code> then handle the input and output
of the process as arrays of binary bytes.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>"directory"</code></term>
<listitem><para>The directory to spawn the process in.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>"err"</code></term>
<listitem><para>Controls where the standard error is sent. By default it is logged
to the journal. If set to <code>"out"</code> it is included in with the
output data. If set to <code>"ignore"</code> then the error output is discarded.
If set to <code>"message"</code>, then it will be returned as the error message.
When the <code>"pty"</code> field is set, this field has no effect.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>"host"</code></term>
<listitem><para>The remote host to spawn the process on. If an alternate user or port is
required it can be specified as <code>"user@myhost:port"</code>. If no host is
specified then the correct one will be automatically selected based on the page
calling this function.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>"environ"</code></term>
<listitem><para>An optional array that contains strings to be used as
additional environment variables for the new process. These are
<code>"NAME=VALUE"</code> strings.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>"pty"</code></term>
<listitem><para>Launch the process in its own PTY terminal, and send/receive
terminal input and output.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>"batch"</code></term>
<listitem><para>Batch data coming from the process in blocks of at least this
size. This is not a guarantee. After a short timeout the data will be sent
even if the data doesn't match the batch size. Defaults to zero.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>"latency"</code></term>
<listitem><para> The timeout for flushing any cached data in milliseconds.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>"superuser"</code></term>
<listitem><para>Set to <code>"require"</code> to spawn the process as root instead of
the logged in user. If the currently logged in user is not permitted to become root
(eg: via <code>pkexec</code>) then the <code>client</code> will immediately be
<link linkend="cockpit-dbus-onclose">closed</link> with a <code>"access-denied"</code>
problem code.</para>
<para>Set to <code>"try"</code> to try to run the process as root, but if that fails,
fall back to an unprivileged process.</para></listitem>
</varlistentry>
</variablelist>
<para>The spawned process is a
<ulink url="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">promise</ulink>
that will complete if the process exits successfully, or fail if there's a problem.
Some additional methods besides the standard promise methods are documented
below.</para>
<para>The standard output of the process is made available via the spawned process
object. Any non-UTF8 output from the process will be coerced into textual form.
It is highly recommended that only textual output be produced by the command.
The standard error is logged to the journal.</para>
</refsection>
<refsection id="cockpit-spawn-script">
<title>cockpit.script()</title>
<programlisting>
process = cockpit.script(script, [args], [options])
</programlisting>
<para>Run a shell script on the system.</para>
<para>This function <link linkend="cockpit-spawn-spawn">spawns</link> a Bourne shell script
process. The full text of the <code>/bin/sh</code> shell script should be passed in as
the first argument. The <code>args</code> can be an array of arguments, not including
the executable, which are passed to the script as <code>$1</code>, <code>$2</code> and
so on. Shebang options are not used or respected.</para>
<para>The <code>options</code> is an optional javascript plain object and can include
any of the fields listed for the
<link linkend="cockpit-spawn-spawn"><code>cockpit.spawn()</code></link> function.</para>
<para>The spawned process is a
<ulink url="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">promise</ulink>
that will complete if the script exits successfully, or fail if there's a problem.
Some additional methods besides the standard promise methods are documented
below.</para>
<para>The standard output of the process is made available via the spawned process
object. Any non-UTF8 output from the process will be coerced into textual form.
It is highly recommended that only textual output be produced by the command.
The standard error is logged to the journal by default.</para>
</refsection>
<refsection id="cockpit-spawn-then">
<title>process.then()</title>
<programlisting>
process.then((data[, message]) => { ... })
</programlisting>
<para>This is a standard
<ulink url="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">promise</ulink>
method. It sets up a handler to be called when the process finishes successfully.</para>
<para>The <code>data</code> argument contains the standard output of the process.
If it a string, unless the process was opened in binary mode, in which case the
<code>data</code> is an array of bytes. If a
<code><link linkend="cockpit-spawn-stream">process.stream()</link></code>
handler is set up, then any standard output data consumed by the handler will not
be included in the <code>data</code> argument.</para>
<para>If the process was spawned with the <code>"err"</code> option set to
<code>"message"</code> then the second argument will contain the standard error
output of the process.</para>
</refsection>
<refsection id="cockpit-spawn-catch">
<title>process.catch()</title>
<programlisting>
process.catch((exception[, data]) => { ... })
</programlisting>
<para>This is a standard
<ulink url="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promise</ulink> method.
It sets up a handler to be called when the process fails, terminates or exits.</para>
<para>The <code>exception</code> object passed to the handler can have the
following fields:</para>
<variablelist>
<varlistentry>
<term><code>message</code></term>
<listitem><para>A message describing the exception. If the process was spawned with
the <code>"err"</code> option set to <code>"message"</code> then the second argument
will contain the standard error output of the process.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>problem</code></term>
<listitem><para>A <link linkend="cockpit-problems">problem code</link> string when
a problem occurred starting or communicating with the process. This is <code>null</code>
if the process exited or was terminated.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>exit_status</code></term>
<listitem><para>The numeric exit status of the process. This is <code>null</code> if
the process did not exit.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>exit_signal</code></term>
<listitem><para>A string representing a unix signal that caused the process to terminate.
This is <code>null</code> if the process did not terminate because of a signal.</para></listitem>
</varlistentry>
</variablelist>
<para>If the process actually ran and produced output before failing, it will be available in
the <code>data</code> argument. Otherwise this argument will be <code>undefined</code>.</para>
</refsection>
<refsection id="cockpit-spawn-stream">
<title>process.stream()</title>
<programlisting>
process.stream(data => { ... })
</programlisting>
<para>This sets up a handler to be called when the process has standard output. The
handler will be called multiple times. The handler will be called regardless of
whether the process ends up exiting successfully or not.</para>
<para>Only one handler may be registered at a time. Registering an additional handler
replaces the previous one. The handler receives either string <code>data</code> or
an array of binary bytes as its argument. A stream handler may return a number, which
indicates the number of characters or bytes consumed from <code>data</code>. Any data
not consumed will be included again the next time the handler is called.</para>
<para>If a <code>process.stream()</code> handler is set up, then the
<code><link linkend="cockpit-spawn-then">process.then()</link></code> handlers will
only get any remaining data not consumed by the stream handler.</para>
</refsection>
<refsection id="cockpit-spawn-input">
<title>process.input()</title>
<programlisting>
process.input(data, [stream])
</programlisting>
<para>This method writes <code>data</code> to the standard input of the process.
If <code>data</code> is <code>null</code> or <code>undefined</code> it is not sent.
The <code>data</code> should be a string or an array of bytes if the process was
opened in binary mode.</para>
<para>If <code>stream</code> is set to <code>true</code> then this function may be
called again with further input. Otherwise the standard input of the process
is closed.</para>
</refsection>
<refsection id="cockpit-spawn-close">
<title>process.close()</title>
<programlisting>
process.close([problem])
</programlisting>
<para>Close the process by closing its standard input and output. If <code>problem</code> is
specified it should be a standard
<link linkend="cockpit-problems">problem code</link> string. In this case the
process will be terminated with a signal.</para>
</refsection>
</refentry>
|
