Solved cron does not send email for some jobs anymore since upgrade

hakova · Apr 17, 2021

Hi all,

I recently upgraded to FreeBSD 13.0 from 12.2. I have a few rsync tasks that are run nightly via cron by the root user. The email address of the root user is defined at /etc/mail/aliases as an external legitimate address. Up until the upgrade, I used the get daily confirmation emails for each of the cronjobs run. Since the upgrade, I am still getting the daily security, ddclient, and some other system task emails, but I stopped getting emails from the custom rsync tasks. Manually running these commands as root work without any error, and yet an email is still not generated/sent. Is there a way to revert back to receiving emails in FreeBSD 13.0?

Thanks for your help.

fjdlr · Apr 17, 2021

For me the problem is the same, I read the release notes, now you have to go through login class, in login.conf
https://www.freebsd.org/releases/13.0R/relnotes/

init (8), service (8), and cron (8) will now adopt user / class environment variables by default (excluding PATH). Notably, environment variables for all cron jobs and rc (8) services can now be set via login.conf (5). 21c1a93c048f, 736a5a6d1dbb, 7466dbd68487

I can't find any info to define these new environment variables

hakova · Apr 18, 2021

Thank you for your reply and troubleshooting. Just for the record I tried adding my email address under the daemon section of the /etc/login.conf, where it reads :mail@:\ like this:
:mail@:user@email.com\
This did not change the behavior.

fjdlr · Apr 18, 2021

Yes, is true, now all changed with the login class:

environment variables for all cron jobs and rc (8) services can now be set via login.conf (5).

I not know make change on files system, login.conf for defined class and path for run this.
I have two workstation one upgrade for tests with 13.0, and my pc server with 12.2.

Thanks, and wait and see others users with same problems

hakova · Apr 22, 2021

I figured out the problem. This didn't have anything to do with the cron daemon or login.conf in my case. What I realized was due to some changes in the sshd_config file during upgrade, more specifically insertion of lines with "<<<<<<<<<<<<<<" and ">>>>>>>>>>>>>>>" as markers of change in this file, sshd daemon was not starting at boot time. Once I deleted those lines, sshd daemon started appropriately, which then allowed my cronjobs that included rsync tasks sending data over ssh to the back up server run without issues followed by appropriate email notifications for completed tasks. I am not sure if this is the problem for you as well fjdlr .

fjdlr · Apr 22, 2021

hakova said:
I figured out the problem. This didn't have anything to do with the cron daemon or login.conf in my case. What I realized was due to some changes in the sshd_config file during upgrade, more specifically insertion of lines with "<<<<<<<<<<<<<<" and ">>>>>>>>>>>>>>>" as markers of change in this file, sshd daemon was not starting at boot time. Once I deleted those lines, sshd daemon started appropriately, which then allowed my cronjobs that included rsync tasks sending data over ssh to the back up server run without issues followed by appropriate email notifications for completed tasks. I am not sure if this is the problem for you as well fjdlr .

Yes this true, sorry i not for posted this, SirDice in other post a resolve this