how to change daily cron emails to go to user account instead of root
freebsd at qeng-ho.org
Tue Sep 1 16:12:39 UTC 2015
On 01/09/2015 16:10, Ernie Luzar wrote:
> Arthur Chance wrote:
>> On 01/09/2015 13:33, Ernie Luzar wrote:
>>> Руслан Бурханов wrote:
>>>> Ernie, look:
>>>> Open you rc.conf, copy string and modify flags for cron daemon:
>>>> cron_flags="-j 60 -m 'YOU at MAIL'"
>>>> Then, restart cron daemon (it is not necessary reboot system):
>>>> /etc/rc.d/cron restart
>>>> Then take a look on cron process:
>>>> ps auxww | grep cron
>>>> If you doing all okey, it will be something like:
>>>> root 561 0.0 0.1 7984 1528 ?? Is 3:16PM 0:00.01
>>>> /usr/sbin/cron -j 60 -m YOU at MAIL -s
>>> Thank you Руслан Бурханов for the informative reply.
>>> I did as you said and still the cron email went to root.instead of to
>>> I edited rc.conf and added this cron_flags="-m 'bob at mydomain'" followed
>>> by "service cron restart" console command.
>>> ps auxww console command showed
>>> root 1953 0,0 0.2 10184 1940 - Is 1:05PM 0:00.30 /usr/sbin/cron -m
>>> bob at mydomain -s
>>> I am running version 10.2 on the host. In the /var/log/maillog file I
>>> can see postfix messages showing root receiving the emails.
>>> rc.conf hostname= option value is the same as the mydomain value in the
>>> cron_flags= option.
>>> Looks and acts like cron is not processing the over ride destination at
>>> daily cron security check time.
>>> Other than this problem of over ridding the cron email destination every
>>> thing seems to be working as one would expect.
>>> Is this enough to declare this a bug and submit a bug report?
>>> Can you suggest other tests I can do to help debug this problem?
>> In the case of mail from periodic (the usual source of mail to root)
>> there is no bug. I've already explained to you that periodic reroutes
>> its output independent of cron's settings, and I've shown you how to
>> deal with that.
>> You've also had the suggestion of using aliases to ensure that any
>> mail to root *whatever its origins* goes to some other user.
>> Have you tried either of those techniques?
> Hello Arthur Chance;
> Thank you for your reply.
> To answer your questions. I have not tried the techniques of postfix
> alias and periodic.conf that you have been so good as to point out.
> Lets step back and look at the big cron picture. Cron is designed as per
> the cron manual pages to use rc.conf cron_flags= option to over ride
> the default "root" destination. Now you state and tests prove that the
> cron periodic routines reroutes its output independent of cron's
> settings. To my way of thinking this is the definition of the bug I am
> experiencing. The periodic routines are in error by not adhering to the
> cron design standard. The periodic routines need code added to them to
> comply with the cron design and check for or use the value in the flags
> option to over ride the destination.
No, cron mails output to the user but periodic is specifically designed
to handle its own output because you can make it send all output to log
files rather than mail. (There's even a default set of files handled by
newsyslog to enable this - the whole thing is very well thought out.)
This is necessary on servers which do not run a mailer and is a design
feature not a bug. Output would simply be lost otherwise.
If you had read the manual page for periodic you'd know this. If you
really insist that periodic must route its output via cron, look at the
option of setting the output variables to an empty string.
> Adding the statements you previous posted to periodic.conf is a
> work-a-round, not a fix or the correct method as per man cron. The goal
> here is not to just get things working by a secondary method, but more
> to the point of getting bugs corrected.
Periodic is a different program from cron with a different set of
requirements. Setting the output variables is not a work round or
secondary method, it's the way periodic works. RTFM is always good advice.
> Thank you for pointing out the cause of this bug. I am going to post a
> bug report on this.
I predict it will be rejected because there is no bug, just the way
things have worked for a long time.
Those who do not learn from computing history are doomed to
More information about the freebsd-questions