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. 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 at shift.agency
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.> 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 at shift.agency > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >-- Stephen J Smoogen.
> 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