stdout/stderr redirection behaving oddly

If none of the more specific forums is the right place to ask

stdout/stderr redirection behaving oddly

Postby dwasi » 2020-06-20 15:10

I have a bunch of scripts, mostly for backup and replication, set up as cron jobs like so:

Code: Select all
00 * * * * /usr/local/bin/replication &> /dev/null


This is intended to redirect all stderr and stdout to /dev/null so I don't get emails to root all the time. For instance that particular script starts out by unmounting any stray shares.

This arrangement has been working well for years, but since upgrading from Stretch to Buster, occasionally an error or an echo statement in the script will slip past /dev/null and wind up generating an email to root. It rarely happens, but when it does occur, it's always the first echo- or error-generating statement in the script. For instance, the replication script starts out like this:

Code: Select all
#Unmount any accidental mounts or leftover mounts
umount /media/failovervar
umount /media/failoveretc
umount /media/failoverstorage
umount /media/failoverusr/local


The resulting occasional root email only ever says this:

umount: /media/failovervar: not mounted.


I never get emails about unmounting any of the other shares. Similarly, in scripts that contain echoes (for when I run them manually), I only ever see the first echo in the script, never any of the subsequent ones.

There are multiple scripts affected, but most of the time they're fine. It's just once in a random while that this happens, like say once or twice a week for scripts that run multiple times every day.

What's going on? Would it help to change from &> /dev/null to > /dev/null 2>&1?
dwasi
 
Posts: 21
Joined: 2019-11-27 16:57

Re: stdout/stderr redirection behaving oddly

Postby Head_on_a_Stick » 2020-06-20 15:14

dwasi wrote:Would it help to change from &> /dev/null to > /dev/null 2>&1?

Yes. The cron jobs use /bin/sh and so should conform to the POSIX specification, "&>" is a bashism.

To avoid this in future install the devscripts package and use
Code: Select all
checkbashisms /path/to/script
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12612
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: stdout/stderr redirection behaving oddly

Postby dwasi » 2020-06-20 15:18

Head_on_a_Stick wrote:
dwasi wrote:Would it help to change from &> /dev/null to > /dev/null 2>&1?

Yes. The cron jobs use /bin/sh and so should conform to the POSIX specification, "&>" is a bashism.

To avoid this in future install the devscripts package and use
Code: Select all
checkbashisms /path/to/script


Thanks, I will do that.

But why does it mostly still work, and why did it always work in Stretch? Just curious now.
dwasi
 
Posts: 21
Joined: 2019-11-27 16:57

Re: stdout/stderr redirection behaving oddly

Postby Head_on_a_Stick » 2020-06-20 15:23

¯\_(ツ)_/¯

I don't really use cron, sorry. I prefer systemd timers in Debian.
Black Lives Matter

Debian buster-backports ISO image: for new hardware support
User avatar
Head_on_a_Stick
 
Posts: 12612
Joined: 2014-06-01 17:46
Location: /dev/chair

Re: stdout/stderr redirection behaving oddly

Postby dwasi » 2020-06-20 16:47

Haha, yep, I get you!

This server predates systemd; I originally set it up with Squeeze and it's been through several updates in place. The Buster implementation is newly built, not updated in place from Stretch, but I mostly just migrated configurations. Never thought about moving to systemd timers until you mentioned it. Maybe now I will.

Thanks bud!
dwasi
 
Posts: 21
Joined: 2019-11-27 16:57


Return to General Questions

Who is online

Users browsing this forum: No registered users and 12 guests

fashionable