What does ‘>/dev/null 2>&1’ mean in this article of crontab basics? [duplicate]
I am reading an article about crontab There is something about disabling automatically sending emails.
- Disable Email By default cron jobs sends an email to the user account executing the cronjob. If this is not needed put the following command At the end of the cron job line.
What is the detailed meaning for 2 > & and 1 ? Why putting this to the end of a crontab file would turn off the email-sending thing?
6 Answers 6
/dev/null is a black hole where any data sent, will be discarded
2 is the file descriptor for Standard Error
& is the symbol for file descriptor (without it, the following 1 would be considered a filename)
1 is the file descriptor for Standard Out
Therefore >/dev/null 2>&1 redirects the output of your program to /dev/null . Include both the Standard Error and Standard Out .
Much more information is available at The Linux Documentation Project’s I/O Redirection page.
cron will only email you if there is some output from you job. With everything redirected to null , there is no output and hence cron will not email you.
What if the command that I run in the crontab file do not output anything? For example something like rm -rf /home/somename/a.txt . In this case, I don’t need to add that, right?
@AwQiruiGuo That’s correct. A mail is delivered only when there is output on stdout or stderr. That’s why they suggest to redirect both to /dev/null in the article.
@SudipBhandari — because there is no redirect symbol ( > ) before it and therefore, unlike the 1 , cannot be mistaken for a filename by the shell.
/dev/null is a device file that acts like a blackhole. Whatever that is written to it, get discarded or disappears. When you run a script that gives you an output and if we add a > /dev/null 2>&1 at the end of the script, we are asking the script to write whatever that is generated from the script (both the output and error messages) to /dev/null .
- 2 is the handle for standard error or STDERR
- 1 is the handle for standard output or STDOUT
2>&1 is asking to direct all the STDERR as STDOUT , (ie. to treat all the error messages generated from the script as its standard output). 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 . Since STDERR is now going to STDOUT (because of 2>&1 ) both STDERR and STDOUT ends up in the blackhole /dev/null . In other words, the script is silenced.
By the way, you need to have a > in front of /dev/null 2>&1 . It should be:
x * * * * /path/to/my/script > /dev/null 2>&1 Linux: Что означает «> /dev/null 2>&1»?
Очень часто в CRON скриптах, можно встретить конструкцию оканчивающуюся на «> /dev/null 2>&1». Без добавления данной записи можно получить огромное количество писем, многие это знают, и как результат делают банальную копиписту, не понимая, что же все-таки на самом деле происходит.
Все дело в перенаправлении вывода.
Оператор > («больше чем»), как в примере выше, переадресовывает вывод программы.
В данном случае, что-то отправляется в /dev/null, а что-то переадресовывается в &1.
Стандартные ввод, вывод и ошибка
Существует три стандартных значения ввода и вывода для программ:
- Ввод получают от клавиатуры или из программы, обрабатывающей вывод другой программы — STDIN.
- Результат программы, обычно отдающийся на стандартной вывод — STDOUT
- И иногда в файл «STDERR» (ошибка).
Часто к ним обращаются не по имени, а по номеру:
0 — STDIN, 1 — STDOUT и 2 — STDERR
По умолчанию, если вы не укажете номер, то будет подразумеваться STDOUT.
В нашем примере видно, что команда направляет свой стандартный вывод в /dev/null (псевдоустройство, которое может принять произвольный объём данных, не сохраняя их). Затем все ошибки (то есть STDERR) перенаправить в стандартный вывод.
Это один из стандартных способов сделать программу безмолвной.
Команда в примере аналогична команде:
cron job command >/dev/null 2>/dev/null
Категория: Администрирование
How do I completely silence a cronjob to /dev/null/?
On my Ubuntu-Desktop and on my debian-server I have a script which needs to be executed each minute (a script that calls the minute-tic of my space online browsergame). The problem is that on debian derivates cron is logging to /var/log/syslog each time it executes. I end up seeing repeated the message it was executed over and over in /var/log/syslog :
Nov 11 16:50:01 eclabs /USR/SBIN/CRON[31636]: (root) CMD (/usr/bin/w3m -no-cookie http://www.spacetrace.org/secret_script.php > /dev/null 2>&1) I know that in order to suppress the output of a program I can redirect it to /dev/null , for example to hide all error and warning messages from a program I can create a line in crontab like this
* * * * * root /usr/local/sbin/mycommand.sh > /dev/null But I would like to run a cronjob and be sure that all generated output or errors are piped to NULL, so it doesn’t generate any messages in syslog and doesn’t generate any emails EDIT:
there is a solution to redirect the cron-logs into a separate log like proposed here by changing /etc/syslog.conf But the drawback is, that then ALL output of all cronjobs is redirected. Can I somehow only redirect a single cronjob to a separate log file? Preferably configurable inside the cron.hourly file itself.
You can also just put MAILTO=»» at the beginning of the cron file. This will suppress all emails. And I’ve never heard of a cron daemon which sends job output to syslog (but I guess it’s possible).
@Patrick — that will disable everything, which might be OK, but just be aware. See my update, you can set multiple mAILTO’s.
Yes, MAILTO=»» as the 1st line of the crontab will prevent any emails. Also, use the full trifecta on your command lines if you are suppressing all output.. All 3 kinds are redirected by this string: >/dev/null 2>&1 — Of course, you can have the scrip include periodic writes to a separate log.
4 Answers 4
* * * * * root /usr/local/sbin/mycommand.sh > /dev/null 2>&1 This will capture both STDOUT (1) and STDERR (2) and send them to /dev/null .
MAILTO
You can also disable the email by setting and then resetting the MAILTO=»» which will disable the sending of any emails.
Example
MAILTO="" * * * * * root /usr/local/sbin/mycommand.sh > /dev/null 2>&1 MAILTO="admin@somedom.com" * * * * * root /usr/local/sbin/myothercommand.sh Additional messaging
Often times you’ll get the following types of messages in /var/log/syslog :
Nov 11 08:17:01 manny CRON[28381]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) These are simply notifications via cron that a directory of cronjobs was executed. This message has nothing to do directly with these jobs, instead it’s coming from the crond daemon directly. There isn’t really anything you can do about these, and I would encourage you to not disable these, since they’re likely the only window you have into the goings on of crond via the logs.
If they’re very annoying to you, you can always direct them to an alternative log file to get them out of your /var/log/syslog file, through the /etc/syslog.conf configuration file for syslog .
@rubo77 — can you show an example? I’d need to see what isn’t working with this. Googling turns this up as the answer: cyberciti.biz/faq/disable-the-mail-alert-by-crontab-command
This works for all output and emails, but it still generates a line for each cron-call in /var/log/syslog
@rubo77 — that’s what I thought you might of been asking about. You can’t stop those messages, they are generated by the crond daemon itself.
@rubo77 — I’m aware of changing /etc/syslog.conf , I would hardly consider this a alternative. That will just change the file that the logs get dumped into or you can completely disable the cron messages all together. There isn’t a way to do what you want.
@rubo77 — the only way you’ll be able to do what you want is if you put a grep -v . after the invoking of the crond .
have a script which needs to be executed each minute. The problem is that cron is logging to /var/log/syslog each time it executes. I end up seeing repeated the message it was ececuted over and over in /var/log/syslog
Since nothing you do seems to stop this, it is worth asking: what exactly is this script and what exactly is the message you see in syslog?
If slm’s suggestion did not work, this is because something is logging to syslog directly — either cron, as seems to be implied in some of your comments, or else the process run by cron. Messages sent to syslog do not come from stdin or stderr, so 2>&1&> will not help.
There might be a way to configure the behavior of the application in question, except we don’t know what it is.
There certainly is a way to configure most contemporary syslog implementations (there are several) to filter messages very specifically. For example, if there is a unique tag used in the log message, you can target that. But again, since we don’t know anything about the particular message, or which syslogd you use, then there’s nothing specific that can be recommended.
My general point is that if you don’t want to redirect/filter messages because «this will redirect all the messages», then you can refine the filtering technique. The server fault thread you linked to just mentions filtering by facility ( *.cron ) — but you can configure more specialized filters than that.
Debian and Ubuntu both have rsyslog available. On debian 5+ it is the default syslog, on ubuntu it is an option, so you’ll have to install it. To create a filter that targets some kind of specific content, place this near the top (i.e., before any other rules, but after the general configuration, module loading, etc) of /etc/rsyslog.conf . Best way to do this is not to edit the rsyslog.conf itself, but to create a file in /etc/rsyslog.conf.d/ directory, with name starting with two digits which are less than 50, ie /etc/rsyslog.conf.d/15-my-filter.conf . You can put there something like this:
:msg, contains, "/usr/bin/w3m -no-cookie" /dev/null This will send the message to /dev/null (or a separate log if you prefer). However, the message will still be passed through the subsequent rules which send it to /var/log/syslog . To prevent that:
Immediately after that other line. This throws away anything which matched the preceding rule. Or, for single-line rules you can just add stop to the end of that rule line.
You have to restart rsyslogd after changing the configuration, (e.g. on systemd systems systemctl restart rsyslog ):
kill -HUP $(cat /var/run/rsyslogd.pid) HUP causes the daemon to restart itself.