Bug 1813623

It's replaced by systemd timer.

commit 8491dee0428b45db4cabf3ddee8bb5b9c6e18f83
Author: Alejandro Domínguez <adomu>
Date:   Sun Feb 9 08:35:31 2020 +0100

    Replace raid-check cron job with systemd timer


--- a/mdadm.spec
+++ b/mdadm.spec
@@ -1,7 +1,7 @@
 Name:        mdadm
 Version:     4.1
 #define subversion rc2
-Release:     2%{?subversion:.%{subversion}}%{?dist}
+Release:     3%{?subversion:.%{subversion}}%{?dist}

> It's replaced by systemd timer

tell me something new when i showed the *disabled* timer state in the initial report after the update and while i am smart enough to understand dnf messages  i doubt that a majority of users are even facing them and don#t expect their raid-chek siltently disabled with a *random* update

* that idiotic update deletes /etc/cron.d/raid-check
* that idiotic update don't enable raid-check.timer
* this is unacceptable behavior in the middle of a sable release

(In reply to Harald Reindl from comment #2)
> > It's replaced by systemd timer
> 
> tell me something new when i showed the *disabled* timer state in the
> initial report after the update and while i am smart enough to understand
> dnf messages  i doubt that a majority of users are even facing them and
> don#t expect their raid-chek siltently disabled with a *random* update
> 
> * that idiotic update deletes /etc/cron.d/raid-check
> * that idiotic update don't enable raid-check.timer
> * this is unacceptable behavior in the middle of a sable release

I agree with your thought but I'm not agree with your words. Everyone can make
faults. 

For this problem, now it already was replaced with systemd service. If we enable
raid-check.timer properly, it doesn't need cron raid-check any more, right?

the tone was because of the "It's replaced by systemd timer" response when my initial report shows that i am not an idiot and quoted the DISABLED state of the timer before i enabled it MANUALLY on my system

and you should simply NOT do such changes randomly on stable releases, NOW keep it please for that case but fix it for others not realizing that they need to do manual actions for random point updates

(In reply to Harald Reindl from comment #4)
> the tone was because of the "It's replaced by systemd timer" response when
> my initial report shows that i am not an idiot and quoted the DISABLED state
> of the timer before i enabled it MANUALLY on my system
> 
> and you should simply NOT do such changes randomly on stable releases, NOW
> keep it please for that case but fix it for others not realizing that they
> need to do manual actions for random point updates

In fact it's not my patch, you can see it in comment1. 

And yes. We should fix this problem. It needs to find a better solution. I think it's
not a good idea that cron raid-check and systemd raid-check exist at the same time. So
we need to choose one.

What's the meaning of "keep it please for that case"? You mean keep systemd raid-check, right?

> I think it's not a good idea that cron raid-check and systemd raid-check exist at the same time

don't get me wrong but you don't understand anything of this bugreport giving that "warning: /etc/cron.d/raid-check saved as /etc/cron.d/raid-check.rpmsave" clearly *removes* cron raid-check (saved as rpmsave means that a user modified confignoreplace file was *removed*)

"keep it please for that case" means that i expect not to have this dance back and forth, now that i have manually enabled it and adjusted the time in a drop-in, it's in updates-testing and just replace it by a update which *enables* raid-check.timer in a post-script

Dear package maintainer, it may makes sense to review and follow https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/#_how_to_enable_a_service_by_default in order to enable your timer by default.

I filed a new bug for the problem https://bugzilla.redhat.com/show_bug.cgi?id=1817491

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

amazing that nobody cares about the outcome of his changes
guess how many ordinary users realize the problem until it's too late

Dear package maintainer, are you still caring about your package? I've filed https://src.fedoraproject.org/rpms/fedora-release/pull-request/158 now to get this hopefully finally addressed...but normally this would have been your turn for 7+ months...

Hi Robert

Can https://bugzilla.redhat.com/show_bug.cgi?id=1817491 fix your problem. There is a same
pull request in this bug.

I installed a f32 and 90-default.preset doesn't enable raid-check. 
@Stephen, could you help to check? Does bug 1817491 really be fixed?

Thanks
Xiao

(In reply to XiaoNi from comment #13)
> I installed a f32 and 90-default.preset doesn't enable raid-check. 
> @Stephen, could you help to check? Does bug 1817491 really be fixed?
> 
> Thanks
> Xiao

You never specified that it needed to be applied to Fedora 32. This change was made for Fedora 33+.

(In reply to Stephen Gallagher from comment #14)
> (In reply to XiaoNi from comment #13)
> > I installed a f32 and 90-default.preset doesn't enable raid-check. 
> > @Stephen, could you help to check? Does bug 1817491 really be fixed?
> > 
> > Thanks
> > Xiao
> 
> You never specified that it needed to be applied to Fedora 32. This change
> was made for Fedora 33+.

https://bugzilla.redhat.com/show_bug.cgi?id=1817491#c4 specified the version(f31/f32/rawhide).
Is it ok to fix this in f32/f31 now?

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.