`console` should be safe

[vkurchatkin]

Using console is potentially unsafe:

//index.js
var fs = require('fs')

process.on('uncaughtException', function (err) {
  fs.writeFileSync('./uncaughtException.txt', err.stack)
})

setInterval(ping, 1000)

function ping () {
  console.log('ping')
}

Then:

iojs index.js &
exit

Yields Error: This socket is closed. This reminds me of old versions of IE where console property was defined only when devtools were open.

[benjamingr]

This also relates to nodejs/node-v0.x-archive#6612 right?

What do you think the behaviour should be?

[vkurchatkin]

I think log and other methods should do nothing when stdout/stderr are not available

[benjamingr]

@vkurchatkin what do most programming languages do here in this case? (C#, Java, Python, Ruby, C++ etc)

[vkurchatkin]

good question. I'll investigate Ruby, Python, go and Objective-C (Cocoa). In Java there are many ways to log something to stdout, but usually System.out.print methods are used. Here are some docs: http://docs.oracle.com/javase/7/docs/api/java/io/PrintStream.html. Basically, they don't throw on error, but set a flag that can be checked with checkError() method.

[bnoordhuis]

@vkurchatkin asked me to comment. It's fairly traditional for properly paranoid UNIX programs to reopen file descriptors 0-2 as /dev/null if they aren't valid file descriptors. I think it's reasonable for io.js to do the same. If opening /dev/null fails, it's probably best to abort.

[vkurchatkin]

Not sure how to detect when 0-2 become invalid. Also, is it really necessary to actually reopen them as /dev/null? this is only important if people use fds directly. We can just swap stdio streams implementation. In fact I think that it's fine if process.stdout.write remains unsafe, I'm talking about console specifically

[bnoordhuis]

Also, is it really necessary to actually reopen them as /dev/null?

Yes, or at least, it's a good idea because it protects against information leaks and worse.

Example: on UNIX platforms, system calls like accept(), open(), socket(), etc. always return the lowest available file descriptor. If stdout is not a valid file descriptor, then the next accept() call uses file descriptor 1 and any logging to stdout gets routed to the socket.

[vkurchatkin]

any logging to stdout gets routed to the socket

I see, that's clearly a problem. I would appreciate some implementation tips or maybe an example of " properly paranoid UNIX program" to look at. Also, what about Windows?

[bnoordhuis]

May I suggest that you review #875? :-)

I don't know about Windows. I don't think you can close stdio on that platform but you'd have to ask @piscisaureus.

[bnoordhuis]

Okay, circling back to file descriptors becoming invalid over the lifetime of the program, I see two possible causes:

1. The controlling terminal going away because the user logs out. The write() system call will start failing with EIO or (possibly?) ENOTTY.
2. Application bugs where the user accidentally closes the wrong file descriptor. Writes will start failing with EBADF but may race with other system calls that return new file descriptors.

The first case seems like something io.js can safely ignore. Printing a warning won't do much good anyway.

The second case arguably merits terminating the process. However, users may start filing bogus bug reports if io.js doesn't print the error. We could work around that by opening /dev/tty but what if the open() call fails? Just plain abort(), I guess.

Downright rejecting or ignoring fs.close() calls with fds <= 2 doesn't sound like a good idea because there are valid use cases for closing stdio file descriptors, like programmatically redirecting them to a file.

[benjamingr]

@bnoordhuis if I understand @vkurchatkin correctly he is not suggesting ignoring writes to closed streams if they were redirected or dup2'd onto etc. He is just suggesting ignoring logs (and only from console.log) - in your response this is the first case (closing terminal).