bootstrap_node.js was directly parsing process.execArgv to see if
internals should be exposed, even though the argv was already parsed by
node. This is unusual and unnecessary, change it to set the option value
from the parser onto the config binding.
PR-URL: https://github.com/nodejs/node/pull/12245
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
A std::string manages its own memory, so using one removes the implicit
assumption that the argv vector passed to node will never be
deallocated. Also, the enabled_categories are used to construct a
std::stringstream, so its simpler to use the standard library
consistently.
PR-URL: https://github.com/nodejs/node/pull/12242
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Put the commit guidelines themselves under a heading to be more
prominent, and to allow linking directly to them (instead of the section
on how to use git).
Link the pull request template to the guidelines, so contributors can
find them.
PR-URL: https://github.com/nodejs/node/pull/11792
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: James M Snell <jasnell@gmail.com>
The Hmac binding layer is not documented as part of the API, and is not
intended to be used, but it should be robust to misuse, and contains
defensive checks for misuse. This test checks that updates without init
throw (as opposed to abort or misbehave in some other way).
PR-URL: https://github.com/nodejs/node/pull/10923
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Some systems may have multiple group names with the same group ID, in
which case getgroups() returns duplicate values, where `id -G` will
filter the duplicates. Unique and sort the arrays so they can be
compared.
PR-URL: https://github.com/nodejs/node/pull/10389
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
__dirname is path.dirname(__filename), but its docs, specifically the
attempt to describe javascript scope in terms of "running" and
"executing" had drifted apart. Rework to describe one as a variation of
the other, move the example, and just describe the names in terms of the
module, and it's local variables rather than the ill defined execution
concepts.
Fix: https://github.com/nodejs/node/issues/5525
PR-URL: https://github.com/nodejs/node/pull/10527
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com>
Passphrase is now used whether keys are provided singly, in an array of
string/buffer, or an array of object, where it used to be ignored in
some argument combinations. Specifically, these now work as expected:
key: [encryptedPem],
passphrase: 'passphrase'
and
key: [{pem: encryptedPem}]
passphrase: 'passphrase'
and
key: [{pem: unencryptedPem}]
PR-URL: https://github.com/nodejs/node/pull/10294
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Document all TLSSocket options:
- All the secure context options are valid options
to a secureContext
- isServer modifies the default value of requestCert
Describe all tls.connect() variants:
- tls.connect(path) was undocumented
- tls.connect(port) was underdocumented, and its relationship to
tls.connect(options) was obscure
Socket passed to tls.connect is user managed:
- Replace https://github.com/nodejs/node/pull/8996
Add documentation to:
- describe and add tests for the pfx and key variants, and describe how
and when passphrase is used.
- describe tls cert and ca options
- describe buffer forms of tls crl option
- describe tls cipher option and defaults
- fix link to Crypto Constants
- describe that honorCipherOrder sets SSL_OP_CIPHER_SERVER_PREFERENCE.
- describe tls ecdhCurve/dhparam options
- describe tls secureProtocol option
- describe tls secureOptions
- describe tls sessionIdContext
De-deduplicate secure context docs:
The secure context options were documented 4 times, making it difficult
to understand where the options come from, where they are supported,
and under what conditions they are used.
The multiple copies were inconsistent and contradictory in their
descriptions of the options, and also inconsistent in whether the
options would be documented at all.
Cut through this gordian knot by linking all APIs that use the
secureContext options to the single source of truth about the options.
PR-URL: https://github.com/nodejs/node/pull/9800
Reviewed-By: Roman Reiss <me@silverwind.io>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Either the options or the listener argument to tls.createServer() was
optional, but not both. This makes no sense, so align the argument
checking and documentation with net.createServer(), which accepts the
same option sequence, and which tls.createServer() is modelled on.
PR-URL: https://github.com/nodejs/node/pull/9800
Reviewed-By: Roman Reiss <me@silverwind.io>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
- Do not use word alias, it isn't well defined
- Fix return value of require() example, which confusingly was not the
exported API as it should have been.
- Fix the require() example, which claimed that the module exported `0`,
when it exports `some_func`.
- Describe best practice in keeping exports and module.exports bound
together.
- Describe why exports exists
- Remove reference to magic, which is also not well defined
PR-URL: https://github.com/nodejs/node/pull/9622
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
In closed environments, self-signed or privately signed certificates are
commonly used, and rejected by Node.js since their root CAs are not
well-known. Allow extending the set of well-known compiled-in CAs via
environment, so they can be set as a matter of policy.
PR-URL: https://github.com/nodejs/node/pull/9139
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Fedor Indutny <fedor.indutny@gmail.com>
- eliminate unnecessary intermediate process ("parent")
- children exit if runner dies unexpectedly (killed on a test timeout,
for example)
- use explicit messaging from children to parents to indicate when
worker is ready to accept http requests, rather than racing to see
whether runner will make request before worker is listening
PR-URL: https://github.com/nodejs/io.js/pull/1944
Reviewed-By: Johan Bergstrom <bugs@bergstroem.nu>
Reviewed-By: Ben Noordhuis <ben@strongloop.com>
When the last signal listener is removed, the signal wrap should be
closed, restoring the default signal handling behaviour. This is done in
a (patched) process.removeListener(). However, events.removeAllListeners
has an optimization to avoid calling removeListener() if there are no
listeners for the 'removeListener' event, introduced in 56668f54d1. That
caused the following code to fail to terminate:
process.stdin.resume();
function listener() {};
process.on('SIGINT', listener);
process.removeAllListeners('SIGINT');
process.kill(process.pid, 'SIGINT')
while the following will terminate:
process.stdin.resume();
function listener() {};
process.on('SIGINT', listener);
process.removeListener('SIGINT', listener);
process.kill(process.pid, 'SIGINT')
Replace the method patching with use of the 'newListener' and
'removeListener' events, which will fire no matter which methods are
used to add or remove listeners.
PR-URL: https://github.com/iojs/io.js/pull/687
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The order of the `newListener` and `removeListener` events with respect
to the actual adding and removing from the underlying listeners array
should be deterministic. There is no compelling reason for leaving it
indeterminate. Changing the ordering is likely to result in breaking
code that was unwittingly relying on the current behaviour, and the
indeterminancy makes it impossible to use these events to determine when
the first or last listener is added for an event.
PR-URL: https://github.com/iojs/io.js/pull/687
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Server sockets should be shared by default, and client sockets should be
exclusive by default. For net/TCP, this is how it is, for dgram/UDP, its
a little less clear what a client socket is, but a socket that is
auto-bound during a dgram.send() is not usefully shared among cluster
workers, any more than an outgoing TCP connection would be usefully
shared.
Since implicit binds become exclusive, implicit/client dgram sockets can
now be used with cluster on Windows. Before, neither explicit nor
implicitly bound sockets could be used, causing dgram to be completely
unsupported with cluster on Windows. After this change, they become half
supported.
PR: https://github.com/iojs/io.js/pull/325
PR: https://github.com/joyent/node/pull/8643
Reviewed-by: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-by: Bert Belder <bertbelder@gmail.com>
The test wasn't checking directly that an assertion was thrown. Instead,
it was checking that spawn did not sucessfully spawn a non-existent
command.
However, the command chosen, dir, exists in GNU coreutils, so it exists
on Linux (though not on BSD derived OS X). The test as written passed on
Linux, even with the TypeError it is supposed to be checking for deleted
from spawn(). It would also pass on Windows if a ls.exe existed.
The approach is unnecessarily obscure, assert.throw() is for asserting
code throws, using it is more clear and works regardless of what
commands do or do not exist.
PR-URL: https://github.com/joyent/node/pull/8454
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
Cherry-picked-from: https://github.com/joyent/node/commit/2ff29cc7e35f486daf86710fd2db48275442c788
Conflicts:
test/parallel/test-child-process-spawn-typeerror.js
Server sockets should be shared by default, and client sockets should be
exclusive by default. For net/TCP, this is how it is, for dgram/UDP, its
a little less clear what a client socket is, but a socket that is
auto-bound during a dgram.send() is not usefully shared among cluster
workers, any more than an outgoing TCP connection would be usefully
shared.
Since implicit binds become exclusive, implicit/client dgram sockets can
now be used with cluster on Windows. Before, neither explicit nor
implicitly bound sockets could be used, causing dgram to be completely
unsupported with cluster on Windows. After this change, they become half
supported.
PR-URL: https://github.com/joyent/node/pull/8643
Reviewed-by: Bert Belder <bertbelder@gmail.com>
For shared handles that do not get connection close messages (UDP/dgram
is the only example of this), cluster must not assume that a port
listened on by one worker is listened on by all workers.
PR-URL: https://github.com/joyent/node/pull/8642
Reviewed-by: Bert Belder <bertbelder@gmail.com>
Callbacks in node are usually asynchronous, and should never be
sometimes synchronous, and sometimes asynchronous.
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
v0.10 and node docs specific that in a worker, the 'message' and 'error'
event emits on process, and on cluster.worker.
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Currently, invalid usage such as:
process.kill('SIGTERM')
process.kill(null)
process.kill(undefined);
all coerce the pid to 0, and signal the current process.
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Documentation claimed it accepted a single label argument, as time and
timeEnd do, which was incorrect.
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Documentation for console.assert incorrectly described message as a
single message, but it is a format.
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Spawn's arguments were documented to be optional, as they are for the
other similar child_process APIs, but the code was missing. Result was
`child_process.spawn('node', {})` errored when calling slice() on an
Object, now it behaves as the documentation said it would.
spawn stdio options can be a 'stream', but the following code
fails with "Incorrect value for stdio stream: [object Object]",
despite being a stream. The problem is the test isn't really
for a stream, its for an object with a numeric `.fd` property,
and streams do not have an fd until their async 'open' event
has occurred. This is reasonable, but was not documented.
child_process.spawn('date', [], {stdio: [
'ignore',
fs.createWriteStream('out.txt',{flags:'a'}),
'ignore']})
Master was disconnecting its workers as soon as they both started up.
Meanwhile, the workers were trying to listen. Its a race, sometimes the
disconnect would happen between when worker gets the response message,
and acks that message with a 'listening'. This worked OK after v0.11
introduced a behaviour where disconnect would always exit the worker,
but once that backwards-incompatible behaviour is removed, the worker
lives long enough to try and respond to the master, and child_process
errors at the attempt to send from a disconnected child.
This is a problem present in both v0.10, and v0.11, where the 'setup'
event is synchronously emitted by `cluster.setupMaster()`, a mostly
harmless anti-pattern.
Fix inadvertent v0.11 changes to the definition of suicide, particularly
the relationship between suicide state, the disconnect event, and when
exit should occur.
In v0.10, workers don't forcibly exit on disconnect, it doesn't give
them time to do a graceful finish of open client connections, they exit
under normal node rules - when there is nothing left to do. But on
unexpected disconnect they do exit so the workers aren't left around
after the master.
Note that a test as-written was invalid, it failed against the v0.10
cluster API, demonstrating that it was an undocumented API change.
Fixes issue in 0.11 where callback doesn't occur if worker count is
currently zero. In 0.10 callback occurs after worker count is zero, and
occurs in next tick if worker count is currently zero.
Sam Roberts