Hi,
we experience difficulties with crond behaviour sending mail since CentOS 8.1. The cron job is the same like we used in CentOS 7.
crontab -l /usr/bin/python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/backup.sh
backup.sh writes the backup to the remote backup server. There are around 30 machines with the same cron job. The python part spreads the jobs over an hour so that the backup server is not struck at once from about 30 machines.
The change in behaviour is that crond sends no mail anymore. It is because of the logical and (&&). Without this crond sends mails.
What has changed in CentOS 8 and does anyone has an idea how we could fix it?
Thank you!
Tobias
On Feb 27, 2020, at 08:01, Tobias Kirchhofer collect@shift.agency wrote:
Hi,
we experience difficulties with crond behaviour sending mail since CentOS 8.1. The cron job is the same like we used in CentOS 7.
crontab -l /usr/bin/python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/backup.sh
Is this literally what your crontab looks like? Because that’s not valid crontab syntax.
backup.sh writes the backup to the remote backup server. There are around 30 machines with the same cron job. The python part spreads the jobs over an hour so that the backup server is not struck at once from about 30 machines.
The change in behaviour is that crond sends no mail anymore. It is because of the logical and (&&). Without this crond sends mails.
What has changed in CentOS 8 and does anyone has an idea how we could fix it?
There aren’t any significant changes in ‘cronie’ in 8.1, looking at the spec file.
Assuming the crontab you wrote above included the time spec too, I’d check to make sure the first command isn’t exiting with a non-zero exit code.
-- Jonathan Billings billings@negate.org
On 27 Feb 2020, at 14:42, Jonathan Billings wrote:
On Feb 27, 2020, at 08:01, Tobias Kirchhofer collect@shift.agency wrote:
Hi,
we experience difficulties with crond behaviour sending mail since CentOS 8.1. The cron job is the same like we used in CentOS 7.
crontab -l /usr/bin/python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/backup.sh
Is this literally what your crontab looks like? Because that’s not valid crontab syntax.
This is what it is literally:
0 5 * * * /usr/bin/python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/backup.sh
backup.sh writes the backup to the remote backup server. There are around 30 machines with the same cron job. The python part spreads the jobs over an hour so that the backup server is not struck at once from about 30 machines.
The change in behaviour is that crond sends no mail anymore. It is because of the logical and (&&). Without this crond sends mails.
What has changed in CentOS 8 and does anyone has an idea how we could fix it?
There aren’t any significant changes in ‘cronie’ in 8.1, looking at the spec file.
Assuming the crontab you wrote above included the time spec too, I’d check to make sure the first command isn’t exiting with a non-zero exit code.
The command chain is running propery, STDOUT output is visible in system log (excerpt from logwatch email):
``` --------------------- Cron Begin ------------------------
**Unmatched Entries** CMDOUT (### Starting backup. Host: host.example.com Backupserver: 10.9.1.5 Path: /borgbackup/vm/host-example-com Date: Fri Mar 20 05:13:46 CET 2020 ###) CMDOUT (Creating archive at "borg@IP:/borgbackup/vm/host-example-com::{now:%Y-%m-%d_%H:%M}") … ```
Its just not sending an email.
What is additionally irritating is that it is only on a few machines. All machines are identically provisioned with ansible.
The situation is not mission critical but it should work. Strange.
Tobias
-- Jonathan Billings billings@negate.org
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
we experience difficulties with crond behaviour sending mail since CentOS 8.1. The cron job is the same like we used in CentOS 7.
Meanwhile we found the reason for the bug - actually we do not know if it is related to a specific version of CentOS or a specific kind of command as cron job.
Let me explain what we have:
- sssd for ssh login of ldap user - crond for cron jobs :)
If we stop sssd and restart crond cron starts to send mails again!
We started with sssd on newly provisioned machines with CentOS 8. We do not know if this is the same on CentOS 7.
We send mails only to root. So no remote user is involved in cron.
From our perspective it is a bug. How could we dive deeper to find the specific reason?
What do you think about this?
Tobias
On 21 Mar 2020, at 11:56, Tobias Kirchhofer wrote:
On 27 Feb 2020, at 14:42, Jonathan Billings wrote:
On Feb 27, 2020, at 08:01, Tobias Kirchhofer collect@shift.agency wrote:
Hi,
we experience difficulties with crond behaviour sending mail since CentOS 8.1. The cron job is the same like we used in CentOS 7.
crontab -l /usr/bin/python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/backup.sh
Is this literally what your crontab looks like? Because that’s not valid crontab syntax.
This is what it is literally:
0 5 * * * /usr/bin/python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/backup.sh
backup.sh writes the backup to the remote backup server. There are around 30 machines with the same cron job. The python part spreads the jobs over an hour so that the backup server is not struck at once from about 30 machines.
The change in behaviour is that crond sends no mail anymore. It is because of the logical and (&&). Without this crond sends mails.
What has changed in CentOS 8 and does anyone has an idea how we could fix it?
There aren’t any significant changes in ‘cronie’ in 8.1, looking at the spec file.
Assuming the crontab you wrote above included the time spec too, I’d check to make sure the first command isn’t exiting with a non-zero exit code.
The command chain is running propery, STDOUT output is visible in system log (excerpt from logwatch email):
--------------------- Cron Begin ------------------------ **Unmatched Entries** CMDOUT (### Starting backup. Host: host.example.com Backupserver: 10.9.1.5 Path: /borgbackup/vm/host-example-com Date: Fri Mar 20 05:13:46 CET 2020 ###) CMDOUT (Creating archive at "borg@IP:/borgbackup/vm/host-example-com::{now:%Y-%m-%d_%H:%M}") …Its just not sending an email.
What is additionally irritating is that it is only on a few machines. All machines are identically provisioned with ansible.
The situation is not mission critical but it should work. Strange.
Tobias
On 5 Apr 2020, at 21:20, Tobias Kirchhofer wrote:
we experience difficulties with crond behaviour sending mail since CentOS 8.1. The cron job is the same like we used in CentOS 7.
Meanwhile we found the reason for the bug - actually we do not know if it is related to a specific version of CentOS or a specific kind of command as cron job.
Let me explain what we have:
- sssd for ssh login of ldap user
- crond for cron jobs :)
If we stop sssd and restart crond cron starts to send mails again!
We started with sssd on newly provisioned machines with CentOS 8. We do not know if this is the same on CentOS 7.
We send mails only to root. So no remote user is involved in cron.
From our perspective it is a bug. How could we dive deeper to find the specific reason?
To sum it up:
- Install CentOS 8 - Enabled and started crond - crond sends emails properly - Enable and start sssd - crond stops sending emails and starts journal logging - Restart crond (or reboot) - crond sends emails and stops journal logging
It is a matter of order. At boot time crond starts after sssd.
This situation is bearable if you know it but has cost us some hours.
Thanks for reading and sorry for this public clarification process ;)
Tobias
What do you think about this?
Tobias
On 21 Mar 2020, at 11:56, Tobias Kirchhofer wrote:
On 27 Feb 2020, at 14:42, Jonathan Billings wrote:
On Feb 27, 2020, at 08:01, Tobias Kirchhofer collect@shift.agency wrote:
Hi,
we experience difficulties with crond behaviour sending mail since CentOS 8.1. The cron job is the same like we used in CentOS 7.
crontab -l /usr/bin/python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/backup.sh
Is this literally what your crontab looks like? Because that’s not valid crontab syntax.
This is what it is literally:
0 5 * * * /usr/bin/python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/backup.sh
backup.sh writes the backup to the remote backup server. There are around 30 machines with the same cron job. The python part spreads the jobs over an hour so that the backup server is not struck at once from about 30 machines.
The change in behaviour is that crond sends no mail anymore. It is because of the logical and (&&). Without this crond sends mails.
What has changed in CentOS 8 and does anyone has an idea how we could fix it?
There aren’t any significant changes in ‘cronie’ in 8.1, looking at the spec file.
Assuming the crontab you wrote above included the time spec too, I’d check to make sure the first command isn’t exiting with a non-zero exit code.
The command chain is running propery, STDOUT output is visible in system log (excerpt from logwatch email):
--------------------- Cron Begin ------------------------ **Unmatched Entries** CMDOUT (### Starting backup. Host: host.example.com Backupserver: 10.9.1.5 Path: /borgbackup/vm/host-example-com Date: Fri Mar 20 05:13:46 CET 2020 ###) CMDOUT (Creating archive at "borg@IP:/borgbackup/vm/host-example-com::{now:%Y-%m-%d_%H:%M}") …Its just not sending an email.
What is additionally irritating is that it is only on a few machines. All machines are identically provisioned with ansible.
The situation is not mission critical but it should work. Strange.
Tobias
On Mon, 6 Apr 2020 at 04:16, Tobias Kirchhofer collect@shift.agency wrote:
On 5 Apr 2020, at 21:20, Tobias Kirchhofer wrote:
we experience difficulties with crond behaviour sending mail since CentOS 8.1. The cron job is the same like we used in CentOS 7.
Meanwhile we found the reason for the bug - actually we do not know if it is related to a specific version of CentOS or a specific kind of command as cron job.
Let me explain what we have:
- sssd for ssh login of ldap user
- crond for cron jobs :)
If we stop sssd and restart crond cron starts to send mails again!
We started with sssd on newly provisioned machines with CentOS 8. We do not know if this is the same on CentOS 7.
We send mails only to root. So no remote user is involved in cron.
From our perspective it is a bug. How could we dive deeper to find the specific reason?
To sum it up:
- Install CentOS 8
- Enabled and started crond
- crond sends emails properly
- Enable and start sssd
- crond stops sending emails and starts journal logging
- Restart crond (or reboot)
- crond sends emails and stops journal logging
It is a matter of order. At boot time crond starts after sssd.
This situation is bearable if you know it but has cost us some hours.
Thanks for reading and sorry for this public clarification process ;)
Tobias
So it sounds like that crond needs to have sssd as a pre-dependency so it doesn't start until sssd is running?
On 6 Apr 2020, at 12:21, Stephen John Smoogen wrote:
On Mon, 6 Apr 2020 at 04:16, Tobias Kirchhofer collect@shift.agency wrote:
On 5 Apr 2020, at 21:20, Tobias Kirchhofer wrote:
we experience difficulties with crond behaviour sending mail since CentOS 8.1. The cron job is the same like we used in CentOS 7.
Meanwhile we found the reason for the bug - actually we do not know if it is related to a specific version of CentOS or a specific kind of command as cron job.
Let me explain what we have:
- sssd for ssh login of ldap user
- crond for cron jobs :)
If we stop sssd and restart crond cron starts to send mails again!
We started with sssd on newly provisioned machines with CentOS 8. We do not know if this is the same on CentOS 7.
We send mails only to root. So no remote user is involved in cron.
From our perspective it is a bug. How could we dive deeper to find the specific reason?
To sum it up:
- Install CentOS 8
- Enabled and started crond
- crond sends emails properly
- Enable and start sssd
- crond stops sending emails and starts journal logging
- Restart crond (or reboot)
- crond sends emails and stops journal logging
It is a matter of order. At boot time crond starts after sssd.
This situation is bearable if you know it but has cost us some hours.
Thanks for reading and sorry for this public clarification process ;)
Tobias
So it sounds like that crond needs to have sssd as a pre-dependency so it doesn't start until sssd is running?
No - if crond is already running and sssd is initially set and starting (after crond) crond does not send mail. For whatever reason. At boot time things are okay, crond starts after sssd. So if sssd is already there, crond is fine. If sssd starts after crond, crond is not fine.
It is a kind of race condition which takes place only in the beginning when sssd is set. Usually crond is in this use case already running, because it is part of (our) base install.
Hope this is clear :)
On Mon, 6 Apr 2020 at 06:59, Tobias Kirchhofer collect@shift.agency wrote:
On 6 Apr 2020, at 12:21, Stephen John Smoogen wrote:
On Mon, 6 Apr 2020 at 04:16, Tobias Kirchhofer collect@shift.agency wrote:
On 5 Apr 2020, at 21:20, Tobias Kirchhofer wrote:
> we experience difficulties with crond behaviour sending mail > since > CentOS 8.1. The cron job is the same like we used in CentOS 7.
Meanwhile we found the reason for the bug - actually we do not know if it is related to a specific version of CentOS or a specific kind of command as cron job.
Let me explain what we have:
- sssd for ssh login of ldap user
- crond for cron jobs :)
If we stop sssd and restart crond cron starts to send mails again!
We started with sssd on newly provisioned machines with CentOS 8. We do not know if this is the same on CentOS 7.
We send mails only to root. So no remote user is involved in cron.
From our perspective it is a bug. How could we dive deeper to find the specific reason?
To sum it up:
- Install CentOS 8
- Enabled and started crond
- crond sends emails properly
- Enable and start sssd
- crond stops sending emails and starts journal logging
- Restart crond (or reboot)
- crond sends emails and stops journal logging
It is a matter of order. At boot time crond starts after sssd.
This situation is bearable if you know it but has cost us some hours.
Thanks for reading and sorry for this public clarification process ;)
Tobias
So it sounds like that crond needs to have sssd as a pre-dependency so it doesn't start until sssd is running?
No - if crond is already running and sssd is initially set and starting (after crond) crond does not send mail. For whatever reason. At boot time things are okay, crond starts after sssd. So if sssd is already there, crond is fine. If sssd starts after crond, crond is not fine.
I must have miscommunicated. I am saying what you are above and wondering if this is a place where putting a custome crond.service in /etc/systemd/system with
[Unit] Description=Command Scheduler After=auditd.service systemd-user-sessions.service time-sync.target sssd.service
[Service] EnvironmentFile=/etc/sysconfig/crond ExecStart=/usr/sbin/crond -n $CRONDARGS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartSec=30s
[Install] WantedBy=multi-user.target
# ====
would fix the race. My apologies for not being clearer.
It is a kind of race condition which takes place only in the beginning when sssd is set. Usually crond is in this use case already running, because it is part of (our) base install.
Hope this is clear :)
-- collect@shift.agency _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Mon, 6 Apr 2020 at 06:59, Tobias Kirchhofer collect@shift.agency wrote:
On 6 Apr 2020, at 12:21, Stephen John Smoogen wrote:
On Mon, 6 Apr 2020 at 04:16, Tobias Kirchhofer collect@shift.agency wrote:
On 5 Apr 2020, at 21:20, Tobias Kirchhofer wrote:
>> we experience difficulties with crond behaviour sending mail >> since >> CentOS 8.1. The cron job is the same like we used in CentOS 7.
Meanwhile we found the reason for the bug - actually we do not know if it is related to a specific version of CentOS or a specific kind of command as cron job.
Let me explain what we have:
- sssd for ssh login of ldap user
- crond for cron jobs :)
If we stop sssd and restart crond cron starts to send mails again!
We started with sssd on newly provisioned machines with CentOS 8. We do not know if this is the same on CentOS 7.
We send mails only to root. So no remote user is involved in cron.
From our perspective it is a bug. How could we dive deeper to find the specific reason?
To sum it up:
- Install CentOS 8
- Enabled and started crond
- crond sends emails properly
- Enable and start sssd
- crond stops sending emails and starts journal logging
- Restart crond (or reboot)
- crond sends emails and stops journal logging
It is a matter of order. At boot time crond starts after sssd.
This situation is bearable if you know it but has cost us some hours.
Thanks for reading and sorry for this public clarification process ;)
Tobias
So it sounds like that crond needs to have sssd as a pre-dependency so it doesn't start until sssd is running?
No - if crond is already running and sssd is initially set and starting (after crond) crond does not send mail. For whatever reason. At boot time things are okay, crond starts after sssd. So if sssd is already there, crond is fine. If sssd starts after crond, crond is not fine.
I must have miscommunicated. I am saying what you are above and wondering if this is a place where putting a custome crond.service in /etc/systemd/system with
[Unit] Description=Command Scheduler After=auditd.service systemd-user-sessions.service time-sync.target sssd.service
[Service] EnvironmentFile=/etc/sysconfig/crond ExecStart=/usr/sbin/crond -n $CRONDARGS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartSec=30s
[Install] WantedBy=multi-user.target
# ====
would fix the race. My apologies for not being clearer.
Just wondering here, if the system crond.service file is being modified/fixed with an update by rpm package, will the custom file in /etc/systemd/system also be fixed then?
Thanks, Simon
On Mon, Apr 06, 2020 at 03:17:29PM +0200, Simon Matter via CentOS wrote:
Just wondering here, if the system crond.service file is being modified/fixed with an update by rpm package, will the custom file in /etc/systemd/system also be fixed then?
No. The packages will only update files in /usr/lib/systemd/system/.
If you drop a file, /etc/systemd/system/crond.service, it will override the one in /usr/lib/systemd. You'll get no benefit from fixes in a package.
If you use /etc/systemd/system/cron.d/service.d/override.conf, the changes in the override.conf will override the contents of /usr/lib/systemd/system/crond.service. So any fixes that appear in a package update will only affect parts of the unit you didn't override.
On Mon, Apr 06, 2020 at 09:26:18AM -0400, Jonathan Billings wrote:
If you use /etc/systemd/system/cron.d/service.d/override.conf, the
I meant /etc/systemd/system/crond.service.d/override.conf, sorry.
On 2/27/20 8:01 AM, Tobias Kirchhofer wrote:
Hi,
we experience difficulties with crond behaviour sending mail since CentOS 8.1. The cron job is the same like we used in CentOS 7.
crontab -l /usr/bin/python3 -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/bin/backup.sh
Agreed on the missing timespec (invalid cron line), but why the mile-long python rather than the simpler:
sleep $((RANDOM % 3600))
Recall percent signs (%) in crontabs means put a newline here, so it needs to be quoted to disable.
Regardless, you say it's not sending mail...that could be silence or say if /usr/bin/python3 didn't exist, should output an error. did you check your mail logs?
-
Chris Schanzle -
Jonathan Billings -
Simon Matter -
Stephen John Smoogen -
Tobias Kirchhofer