> 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