Signals represent a limited form of inter-process communication. When a signal is issued to a process, it will be interrupted and a signal handler will be executed. If there is no signal handler, the default handler will be called instead. This sounds a lot like asynchronous events in Node, and that's exactly how signals are implemented; using process.on:
Running the command with & to put it in the background will actually display the PID in most shells, but I put process.pid in there just to demonstrate how to get the PID in Node. Once you've sent a few signals to it, issuing a SIGINT will end the process.
Usage in Node
A common use of signal events in Node is to perform some kind of cleanup when a process is terminated. Where signals really come in handy is for communicating with daemons. Many daemons accept SIGHUP to reload configuration files -- I followed the same convention when I built an IRC daemon in Node. Another convention is to listen for SIGTERM to perform a graceful shutdown. This could be used to close down sockets, database connections, or remove any temporary files.
I believe Node is a great solution for writing Unix daemons. It's a good idea to follow established conventions, so add listeners for SIGHUP and SIGTERM.