I'd like to disable at mail notifications for a certain class of jobs. For example, when testing the use case below (killing an at job midstream) I don't want output, but the same code in production I do want the mailed output:

$ at now <<<'/usr/bin/timeout 15s nc -l 20242'
job 71 at 2016-05-16 15:03
$ pidof /usr/bin/timeout
$ kill 11853
$ mail
Heirloom Mail version 12.4 7/29/08.  Type ? for help.
"/var/spool/mail/bishop": 1 message 1 new
>N  1 bishop@trencher  Mon May 16 15:03  16/920   "Output from your job       71"
& 1
Message  1:
From bishop@trencher  Mon May 16 15:03:30 2016
Date: Mon, 16 May 2016 15:03:30 -0400
From: bishop@trencher
Subject: Output from your job       71
To: bishop@trencher
Status: R

/bin/bash: line 1: 11853 Terminated              /usr/bin/timeout 15s nc -l 20242

I know I can set MAILPATH=/dev/null, but I'd prefer to have more fine grained control. Setting MAIL and MAILTO have had no obvious effect. I thought I could edit the job to remove the # mail directive, but that doesn't seem to work:

at 15:15 <<<'date'
at -c 73 | grep -v '^# mail bishop' | at 15:15
atrm 73

I've searched high and low, but let's just say searching for a command named at is non-trivial. I can't even seem to find the at source code: isn't it in GNU coreutils?

UPDATE: Station identification:

$ uname -a
Linux trencher 4.4.8-20.46.amzn1.x86_64 #1 SMP Wed Apr 27 19:28:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ at -V
at version 3.1.10

Is it possible to control, per job, whether the output -- any output -- is mailed to the submitting user?

  • What version of at do you have? The -M Never send mail to the user bit in the manual for the one on RedHat 6 looks promising. Otherwise, you'll probably have to nix all stdout/stderr on the development boxes at jobs. – thrig May 16 '16 at 19:33
  • Can you give us more information about your OS Version/Distro, please? – Grimdari May 16 '16 at 19:57
  • @thrig Same thing in the manual on my Debian testing box. Suspect it's widespread and you should post that as an answer. – derobert May 16 '16 at 20:03
  • @thrig Regrettably, no -M. I have -m (small case "m"), but that's described as "Send mail to the user when the job has completed, even if there was no output." – bishop May 16 '16 at 20:17
  • @Grimdari uname -a added. – bishop May 16 '16 at 20:17

The RedHat (and thus Centos and friends) at and also Debian-derived vintages (as rpm -qi at on RedHat indicates a Debian URL, and also derobert in comments, above) should support a -M option:

    -M      Never send mail to the user.

Lacking this, another option would be to suppress output from the job:

exec >/dev/null 2>&1
... the usual job commands here ...

Or, instead pipe the output to logger or to a log file in the event the output does need to be inspected.

Yet another option would be to alter the mail transport agent, especially since these are development systems, and to drop all mail to /dev/null or into a mailbox file somewhere on the development server, but that's more work.

  • In my test environment, I have a function that just wraps my command in a bash script with the stdout and stderr exec'd to dev null. Works well enough, though I'd love to have -M for its simplicity. Thanks for the detailed answer! – bishop May 17 '16 at 13:12
  • So you never know if anything fails? – Walf May 29 '17 at 1:15
  • 1
    @Walf That would seem to be the point of the question, yes. Sometimes you really don't care if a task succeeds or not, you just want it to make a best effort. If it fails, c'est la vie and don't bother me about it. – jmbpiano Jun 1 '17 at 23:58

Precede the command passed to at with chronic (from the moreutils package) so that you still get both stderr and stdout, if the command exited with an error status, otherwise nothing.

Do the same to your cron jobs while you're at it.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.