countme: Trigger on boot and bi-weekly with random delay #3041
Conversation
|
Untested yet. Will do that next week. |
|
Hmm. In theory we could use something like GNetworkMonitor to reliably react to network connectivity rather than failing. In other words, if the network isn't available we sleep until it is, rather than exiting with failure. That said, the network availability check may not be 100% accurate, so we may want to have unit restarts anyways. But, I think it'd be good to avoid restarting on all failures - only if we detect a network issue. (OK well, I guess from this service the only real issues can be network) But it looks like systemd offers |
|
I've tried to figure out how to set a different return code but haven't been able to do that yet. Will keep looking next week. |
travier
force-pushed
the
countme-retry
branch
from
a680bba to
0d53a0c
Compare
|
Updated with suggestion from #3041 (comment). Still untested. Will have to figure out a way to test that. |
|
I'm not completely sold on the way that I implemented this but this is the simplest one I could figure out short of defining a new Error type. |
travier
force-pushed
the
countme-retry
branch
from
0d53a0c to
3d112a9
Compare
travier
force-pushed
the
countme-retry
branch
from
3d112a9 to
279fac4
Compare
|
|
Hum, this fails before calling the code here so this is extra weird. Re-testing. |
travier
force-pushed
the
countme-retry
branch
from
c63e6a9 to
d8c3307
Compare
|
2nd commit LGTM - thanks for stepping through that with me @travier |
travier
force-pushed
the
countme-retry
branch
from
d8c3307 to
7a8e467
Compare
The current timer will trigger weekly with a potential delay of a week, which means that if the delay is big enough, an entire week will be skipped and we will miss counting. Instead, let's trigger on boot and every three days with a random delay of one day so that we are sure that we at least trigger once per counting window. This does not introduce the risk of over counting as the logic for that check is in rpm-ostree itself.
travier
force-pushed
the
countme-retry
branch
from
7a8e467 to
791ce7b
Compare
|
OK, this keeps failing in CI and I don't understand why so I'm trying to split the changes to figure out the root issue. |
|
travier
changed the title
|
Re-purposing this PR for the "second" change from @dustymabe until I find another fix. We might have to do the initial suggestion from #3033 where we move the trigger logic in the code itself instead of systemd. |
|
anything else needed for this? |
- Update link to official DNF Configuration Reference documentation. - Mention that the timer is now triggered on boot after 5 minutes and then bi-weekly, with a random delay in both cases. See: coreos#3041
- Update link to official DNF Configuration Reference documentation. - Mention that the timer is now triggered on boot after 5 minutes and then bi-weekly, with a random delay in both cases. See: coreos#3041
- Update link to official DNF Configuration Reference documentation. - Mention that the timer is now triggered on boot after 5 minutes and then bi-weekly, with a random delay in both cases. See: #3041
The current timer will trigger weekly with a potential delay of a week,
which means that if the delay is big enough, an entire week will be
skipped and we will miss counting.
Instead, let's trigger on boot and every three days with a random delay
of one day so that we are sure that we at least trigger once per
counting window.
This does not introduce the risk of over counting as the logic for that
check is in rpm-ostree itself.