![]() Most firewalls (and routers for household use) can be configured to silently discard packets addressed to forbidden hosts or ports, resulting in small or large "black holes" in the network. For example, 198.51.100.0 / 24 is reserved for use in documentation and examples by RFC 5737 while the RFC advises that the addresses in this range are not routed, this is not a requirement. Connection-oriented or reliable protocols (TCP, RUDP) will either fail to connect to a dead address or will fail to receive expected acknowledgements.įor IPv6, the black hole prefix 100:: / 64 is described by RFC 6666.įor IPv4, no black hole address is explicitly defined, however the reserved IP addresses can help achieve a similar effect. Note that a dead address will be undetectable only to protocols that are both connectionless and unreliable (e.g., UDP). The most common form of black hole is simply an IP address that specifies a host machine that is not running or an address to which no host has been assigned.Įven though TCP/IP provides a means of communicating the delivery failure back to the sender via ICMP, traffic destined for such addresses is often just dropped. ![]() When examining the topology of the network, the black holes themselves are invisible, and can only be detected by monitoring the lost traffic hence the name as astronomical Black holes cannot be directly observed. File descriptor 2 is still redirected to stdout, no matter what happens to file descriptor 1.In networking, a black hole refers to a place in the network where incoming or outgoing traffic is silently discarded (or "dropped"), without informing the source that the data did not reach its intended recipient. Indeed, in the later case, file descriptor 2 is set to the current address of file descriptor ``1 (which is stdout at this very moment), and then the file descriptor 1 is redirected to /dev/null. Try these two commands with a non-privileged user: ls >/dev/null 2>&1 Warning: the order of redirection matters: >/dev/null 2>&1 As such, no output is produced and no mail is sent. Is redirecting the error stream to the output stream, which has been redirected to /dev/null. stdout) and file descriptor 2 is standard error (a.k.a. & is the address operator as in the C language.Ĭonventionally, file descriptor 1 is standard output (a.k.a. Will redirect to file descriptor n (or standard output if unspecified) to file descriptor fd.Ī file descriptor can be a file name of the address of a stream. Now to the syntax: this is specific to the Bourne shell language (and its derivatives such as bash, zsh, and so on). So what your article suggests here is to produce no output, thus sending no mail.Īnother way (more convenient?) to disable mail is to use the -m off option, i.e. When executing commands, any output is mailed to the owner of the crontab. It should be: x * * * * /path/to/my/script > /dev/null 2>&1 ![]() ![]() In other words, the script is silenced.īy the way, you need to have a > in front of /dev/null 2>&1. Since STDERR is now going to STDOUT (because of 2>&1) both STDERR and STDOUT ends up in the blackhole /dev/null. Now we already have > /dev/null at the end of the script which means all the standard output ( STDOUT) will be written to /dev/null. to treat all the error messages generated from the script as its standard output).
0 Comments
Leave a Reply. |