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.