> On Mon, 6 Apr 2020 at 06:59, Tobias Kirchhofer <collect at 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 at 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