Bug 1187111

AFAIK, timers disabled by default

(In reply to Igor Gnatenko from comment #1)
> AFAIK, timers disabled by default

It is not and irrelevant since those timer units should not exist in the first place

1.
"All packages with timed execution which already depend on systemd (for example because they contain systemd units) must use timer units instead of cron jobs, with no dependency or requirements on a crontab. "
- DNF requires systemd, accomplished, we are using timer units

"Packages which do not already depend or require systemd must not use timer units but instead depend and have requirement on crontabs, to avoid introducing unnecessary new dependencies on systemd directly. "
- not relevant to DNF, see answer above

In case you post wrong link, feel free to reopen.


2.
dnf-makecache.timer activates 10 min after boot.
dnf-automatic.timer activates 1 hour after boot.


3.
Thanks to systemd you can use fully equipped DNF with fresh metadata. If you have FUP connection you can disable metadata syncing by setting configuration option `metadata_timer_sync` to 0.

(In reply to Jan Silhan from comment #3)
> 1.
> "All packages with timed execution which already depend on systemd (for
> example because they contain systemd units) must use timer units instead of
> cron jobs, with no dependency or requirements on a crontab. "
> - DNF requires systemd, accomplished, we are using timer units
> 
> "Packages which do not already depend or require systemd must not use timer
> units but instead depend and have requirement on crontabs, to avoid
> introducing unnecessary new dependencies on systemd directly. "
> - not relevant to DNF, see answer above
> 
> In case you post wrong link, feel free to reopen.


I see I'm dealing with one of those Red Hat genius is there not a smarter individual in the company who can handle this, 

You understand you are speaking with the guy responsible for the cron to time migration and you are purposely misinterpret the guidelines

For the first DNF does not require systemd in any shape or form hence 

"Packages which do not already depend or require systemd must not use timer"

Already applied

You yourself added timer units in violation of those guidelines and hence introduced unnecessary dependency on core/baseOS component

Drop those unit files and add a cron script and depend on the virtual provide for that cron jobs in that ( package or sub-package if you prefer )

Let me put this other way. 

If DNF did *not* ship the timer units would it still depend on systemd? 

If the answer to that is yes then you can ship those timer units and close this bug with explanation how or why it depends on systemd  

If the answer to that is no you cannot and need to drop those unit files.

What's the rational behind periodical creation of cache other than to systematically waste peoples download quota/bandwidth?

why cannot this be triggered when users simply run dnf manually or some application does?

Is it safe to assume the existence of those units are due to either some copy/paste mistake from yum or someone ( propbably cloud/baseWG member these days ) suggesting this to get rid of dependency on cron ( and obfuscate correct dependency in the core/baseOS in the process ) which could have been equally achieved via sub component containing the original cron job and that sub component could have been removed and or excluded at install time to achieve the same effect ( guess to shrink the size and or get rid of dependency on cron ) but at the same time ensure the correct dependency path on components that make up the core/baseOS?

This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

see comment 3

Reopening based on comment 4. 

You added the dependency on systemd by introducing needless timer units for dnf. 

DNF is not dependend on systemd to function correctly not does it ship a daemon/service unit which the timer unit should be bound to.

Fedora officially supports systems and doesn't work (officially) without systems. So it's your problem rather than DNF

Reopening only cron scripts that already depended on systemd packages should have been migrated to native systemd timer. Components that dont depend on systemd should not ship native systemd timers but use the traditional cron job instead and depend on crontab. 

Last time I checked there had not been system wide feature for Fedora to stop shipping cron or components that provide cron like functionality and until it does and the packaging guidelines are updated to reflect that, that timer unit should not be shipped nor should dnf depend on systemd since it ships that unit.

This change breaks akmod system. Please get ride of use dnf a boot time.

I did some investigation as to why akmod will fail to install a
the nvidia dirver when a new kernel turns up.

The problem is that dnf-makecache.service runs at the same time
as akmods.service. DNF locks the RPM data base which prevents
akmods from installing the RPM's it built.

Here is a extract from 346.72-2.1-for-4.0.8-300.fc22.x86_64.failed.log

Running transaction
RPMDB already locked by 2285
 The application with PID 2285 is: dnf
   Memory : 116 M RSS (677 MB VSZ)
   Started: Sat Jul 18 12:09:56 2015 - 06:20 ago
   State  : Sleeping
2015/07/18 12:16:16 akmods: Could not install newly built RPMs. You can
find them and the logfile 2015/07/18 12:16:16 akmods:
346.72-2.1-for-4.0.8-300.fc22.x86_64.failed.log
in /var/cache/akmods/nvidia/ Looking in the journal shows dnf-makecache
running at the time that akmods.service need RPMDB access.

I ended up working around the issue with:

	systemctl disable dnf-makecache.service
	systemctl disable dnf-makecache.timer

I'm not sure what the right systemd unit change will be to have a
reliable start up. How do you prevent dnf-makecache from running
until after akmods.service has run given that started off a timer?

At the next kernel release I'll know if this is successful.

(Please note that my following comment does not express my opinion on the original concern of shipping the timers with DNF. Also please note that I am not very familiar with neither akmod system nor systemd.)

I wonder whether disabling dnf-makecache is the best solution for the akmod problem. There might be any other service requiring an RPMDB access as well. Are you going to personally ask every such component to make sure that it is not run at the same time as akmod? Shouldn't there be a Fedora policy then? I think that akmod should rather be more robust or should find a way how to enforce it's requirement to be run alone. But it's fairly possible that I've missed something.

(We can discuss it somewhere else in order to avoid an off-topic discussion.)

(In reply to Jóhann B. Guðmundsson from comment #6)
> What's the rational behind periodical creation of cache other than to
> systematically waste peoples download quota/bandwidth?
> 
> why cannot this be triggered when users simply run dnf manually or some
> application does?
> 
I agree. The system is your (you are the maintainers) but resources are mine. The timer should be disabled by default. If user needs (or wants) then can enable it. A question while installing could be a solution.

(In reply to Massimiliano from comment #14)
> (In reply to Jóhann B. Guðmundsson from comment #6)
> > What's the rational behind periodical creation of cache other than to
> > systematically waste peoples download quota/bandwidth?
> > 
> > why cannot this be triggered when users simply run dnf manually or some
> > application does?
> > 
> I agree. The system is your (you are the maintainers) but resources are
> mine. The timer should be disabled by default. If user needs (or wants) then
> can enable it. A question while installing could be a solution.

This bug report is about the violation of the approved Fedora Packaging Guidelines ( there is no point of having guidelines if nobody follows it ) in which they have introduced systemd timer units but should be using cron script instead ( which would not create the issue Barry here is now dealing with the akmod package nor otherwise have any affect on the boot process as in delay it ) with their component supposed to be depending on crontab so their option in relation to this bug report is either a) drop the systemd timer units and use an cron job instead ( as they are supposed to do and always should have been doing ) or  b) Make the necessary changes to the Fedora Packaging Guidelines which will in turn indirectly obsolete the use and shipping for cron and cron related packages.

With Red Hat pushing the distribution to it's model and "products" ( which now has been renamed to "editions" since someone at Red Hat marketing figured out that this was too obviously close to Red Hat products ) there exist no such thing as "system wide default" anymore hence package maintainers have absolutely no control over what is enabled or disabled or for that matter in control if their components is installed or otherwise part of a spesific product.

That control has been moved entirely to the working groups that exist around each ( Red Hat ) product and may or may not differ depending on which ( Red Hat ) product you are using so regardless if the DNF package maintainers here would want to do the right thing in which they should have done from the get go as in follow the same path as yum-cron did and have this provide functionality an opt-in process instead of opt out process it's completely out of their control now.

(In reply to Radek Holy from comment #13)
> (Please note that my following comment does not express my opinion on the
> original concern of shipping the timers with DNF. Also please note that I am
> not very familiar with neither akmod system nor systemd.)
> 
> I wonder whether disabling dnf-makecache is the best solution for the akmod
> problem. There might be any other service requiring an RPMDB access as well.
> Are you going to personally ask every such component to make sure that it is
> not run at the same time as akmod? Shouldn't there be a Fedora policy then?
> I think that akmod should rather be more robust or should find a way how to
> enforce it's requirement to be run alone. But it's fairly possible that I've
> missed something.
> 
> (We can discuss it somewhere else in order to avoid an off-topic discussion.)

RPM Fusion users list? rpmfusion-users.org

(In reply to Jóhann B. Guðmundsson from comment #15)
> > I agree. The system is your (you are the maintainers) but resources are
> > mine. The timer should be disabled by default. If user needs (or wants) then
> > can enable it. A question while installing could be a solution.
> 
> This bug report is about the violation of the approved Fedora Packaging
> Guidelines

Just a clarification due my bad english. I say "disabled" but I mean "not present" or "not installed". I say "enable" but I mean "install". Maybe this service breaks the current rules, but I'm wondering about the absolute need to have it.

Sorry again for my english.

(In reply to Massimiliano from comment #17)
> (In reply to Jóhann B. Guðmundsson from comment #15)
> > > I agree. The system is your (you are the maintainers) but resources are
> > > mine. The timer should be disabled by default. If user needs (or wants) then
> > > can enable it. A question while installing could be a solution.
> > 
> > This bug report is about the violation of the approved Fedora Packaging
> > Guidelines
> 
> Just a clarification due my bad english. I say "disabled" but I mean "not
> present" or "not installed". I say "enable" but I mean "install". Maybe this
> service breaks the current rules, but I'm wondering about the absolute need
> to have it.
> 
> Sorry again for my english.

If it would have followed the packaging guidelines and existing yum cron implementation it would have been a cron script, package in a sub package, with that sub package depended on crontab and end user and working groups could have exclude or included that sub package but here we are with yet another component added to the existing pile of incorrectly packaged components in the core/baseOS with non existing or incorrect dependencies in it.

Bug 928726 and Bug 878826 seem related to this.

Irrelevant to this report and Harald Hoyer could have contacted me directly before filing the request for the timer units since I was the feature owner of the cron to timer migration and went through all the roughly 100 components that shipped cron scripts ( including yum-cron ) and determine what should or should not be migrated to systemd timers in the distribution and I would have told him that this belong as a cron script in a separated sub package which could be excluded and achieve the same goal.

I also am the individual responsible for the changes to the packaging guidelines both for timers as well as cron which makes so funny when Jan here is trying to educate *me* in what those guidelines mean or how they where indented to be used. ( by all means carry on Jan continue to enlighten me about it's meaning ) 

When the dnf packagers in the distribution have fixed this they have then they will have to fix dnf-automatic.timer to be cron scripts instead ( or at the same time ).

(In reply to Radek Holy from comment #13)
> (Please note that my following comment does not express my opinion on the
> original concern of shipping the timers with DNF. Also please note that I am
> not very familiar with neither akmod system nor systemd.)
> 
> I wonder whether disabling dnf-makecache is the best solution for the akmod
> problem. There might be any other service requiring an RPMDB access as well.
> Are you going to personally ask every such component to make sure that it is
> not run at the same time as akmod? Shouldn't there be a Fedora policy then?
> I think that akmod should rather be more robust or should find a way how to
> enforce it's requirement to be run alone. But it's fairly possible that I've
> missed something.
> 
> (We can discuss it somewhere else in order to avoid an off-topic discussion.)

I am on Fedora Devel which might be the best forum.

Barry

Now, I'm subscribed to both. However, I don't know what else to say. I was just curious whether you agree with me that there might be a better solution. I got an impression from your email on rpmfusion-users that you are also looking for something more systematic. So, now, I'm just watching these lists and waiting if someone suggests a solution to you.

(In reply to Jóhann B. Guðmundsson from comment #20)
> I also am the individual responsible for the changes to the packaging
> guidelines both for timers as well as cron

Great to know that. I am sorry but we don't have the time to constantly changing the implementation as you decide. You have requested we should use systemd (bug 878826), now you want for us to use crons again. With respect I don't see any crucial benefit for users once we switch back to cron scripts.

systemd is used for regular makecache (main feature of DNF) and `rpm-plugin-systemd-inhibit` requires it for rpm transactions.

Having the makecache timers in separate subpackage could be an option but in that case then we would break the API as user will not be able to configure the timer from dnf main configuration file.

(In reply to Barry Scott from comment #12)
> This change breaks akmod system. Please get ride of use dnf a boot time.

Finally we hit the "real" problem in this report.

> I did some investigation as to why akmod will fail to install a
> the nvidia dirver when a new kernel turns up.
> 
> The problem is that dnf-makecache.service runs at the same time
> as akmods.service. DNF locks the RPM data base which prevents
> akmods from installing the RPM's it built.
> 
> Here is a extract from 346.72-2.1-for-4.0.8-300.fc22.x86_64.failed.log
> 
> Running transaction
> RPMDB already locked by 2285
>  The application with PID 2285 is: dnf
>    Memory : 116 M RSS (677 MB VSZ)
>    Started: Sat Jul 18 12:09:56 2015 - 06:20 ago
>    State  : Sleeping
> 2015/07/18 12:16:16 akmods: Could not install newly built RPMs. You can
> find them and the logfile 2015/07/18 12:16:16 akmods:
> 346.72-2.1-for-4.0.8-300.fc22.x86_64.failed.log
> in /var/cache/akmods/nvidia/ Looking in the journal shows dnf-makecache
> running at the time that akmods.service need RPMDB access.

You should have filed a different bug report for this issue. How does switching back to cron job fix this issue? IMO the RPMDB would be still locked.

> I ended up working around the issue with:
> 
> 	systemctl disable dnf-makecache.service
> 	systemctl disable dnf-makecache.timer
> 
> I'm not sure what the right systemd unit change will be to have a
> reliable start up. How do you prevent dnf-makecache from running
> until after akmods.service has run given that started off a timer?

The dnf-makecache.timer has set OnBootSec=10min. Could akmods.service start earlier after boot? Could making the rpmdb lock blocking (if we don't have already) solve the issue, Michal?

(In reply to Jan Silhan from comment #23)
> (In reply to Jóhann B. Guðmundsson from comment #20)
> > I also am the individual responsible for the changes to the packaging
> > guidelines both for timers as well as cron
> 
> Great to know that. I am sorry but we don't have the time to constantly
> changing the implementation as you decide. You have requested we should use
> systemd (bug 878826), now you want for us to use crons again. With respect I
> don't see any crucial benefit for users once we switch back to cron scripts.

More of your bullshit I never made such a request which you could easily see if you actually bother to look at who filed that report and you should have simply taken 5 minutes of your time and actually contacted the feature owner of the implementation of timers in the distribution and ask should we implement this as a timer or cron script and I would have respond with no.  

Now revert this implementation or file request to change the packaging guidelines.

> Now revert this implementation or file request to change the packaging
> guidelines.

Jóhann, considering Jan's rationale in comment 23, I don't think your request is valid any more. The guidelines clearly state that a package should use systemd timer if it already requires systemd. As Jan stated and as you can see for yourself, dnf uses rpm-plugin-systemd-inhibit therefore it transitively depends on systemd and usage of its timers is justified. Converting them to cron jobs and depending on cron would lead to dependency bloat which is explicitly against Fedora intentions.

I suggest either focusing on the problem with akmods and changing the summary of this bug accordingly or closing this bug and filing another for that issue.

(In reply to Jan Zeleny from comment #25)
> > Now revert this implementation or file request to change the packaging
> > guidelines.
> 
> Jóhann, considering Jan's rationale in comment 23, I don't think your
> request is valid any more. The guidelines clearly state that a package
> should use systemd timer if it already requires systemd. 


Explain to me how it already depended on systemd before the introduction of systemd timer units. 

What daemon/service units does DNF use and or provide that made it dependent in systemd in the first place?

Looking at the code I dont see any prior dependency on systemd *before* the introduction of the timer units so by all means explain to me how comment 23 is relevant and how DNF already required systemd before their introduction.

You are correct. It was a mistake to switch to systemd those two and a half years ago. I will not argue about that. Let's not make this discussion academic. The situation is different now, as systemd is utilized by dnf to make sure system doesn't go into shutdown in the middle of transaction. Therefore, the present state is not against the guidelines and from the practical perspective it makes more sense to keep it this way to reduce the dependencies in the base system.

(In reply to Jan Zeleny from comment #28)
> You are correct. It was a mistake to switch to systemd those two and a half
> years ago. I will not argue about that. Let's not make this discussion
> academic. 

Good to finally see that you admit that implemented this was in violation of the approved Fedora packaging guidelines and interesting to see to what extent you take to cover it up. It only took over half a year to do so.

> The situation is different now, as systemd is utilized by dnf to
> make sure system doesn't go into shutdown in the middle of transaction.

Which should not be necessary. 

> Therefore, the present state is not against the guidelines and from the
> practical perspective it makes more sense to keep it this way to reduce the
> dependencies in the base system.

You are not increasing the dependency in the core/base OS by having those timer unit cron scripts instead and packaged separately with virtual dependency on crontab. 

Those would be excluded altogether from minimal based install anyway ( at least dnf-automatic has valid usecase behind it, the makecache stuff makes absolutely no sense et all ) and even DNF altogether and probably entirely in the future when LEGO-like distro assembly at the end users machines and servers in data centers becomes obsoleted with immutable crytopgraphically secured images for /usr being used for installation and updates/upgrades. 
( Which probably is on the roadmap for RHEL 9 since RH is already busy manipulating Fedora into it's products and has been for quite a while now with Will re-implementing the upgrade mechanism yet again in it's broken form and probably for ever until that happens since he did not know what he signed himself into all those years ago when he was playing pre-upgrade with Jeremy )

If the intent is to leave things as they are then I have to ask why does that makecache timer unit exist in the first place, what's the usecase for it? why is it not package in a seperate sub component like the automatic timer units and why is it enabled by default?

(In reply to Jóhann B. Guðmundsson from comment #29)
> If the intent is to leave things as they are then I have to ask why does
> that makecache timer unit exist in the first place, what's the usecase for
> it? why is it not package in a seperate sub component like the automatic
> timer units and why is it enabled by default?

For user experience. User/Admin will already have latest metadata when he will run dnf something instead of waiting while dnf will download it.

(In reply to Igor Gnatenko from comment #30)
> (In reply to Jóhann B. Guðmundsson from comment #29)
> > If the intent is to leave things as they are then I have to ask why does
> > that makecache timer unit exist in the first place, what's the usecase for
> > it? why is it not package in a seperate sub component like the automatic
> > timer units and why is it enabled by default?
> 
> For user experience. User/Admin will already have latest metadata when he
> will run dnf something instead of waiting while dnf will download it.

If it's for the user experience it's best to download that *always* on demand since it's the only way to ensure that the end user is working on the latest metadata since the metadata can be obsoleted between the interval the timer unit or the cron script is configured to run + the time it takes to download it is no more then the time it takes to download a single package of average size and last time I checked DNF took it's time to download all packages again and again if encountered simple transaction failure. 

End users and administrators simply run dnf update -y press enter and wait for updates to complete. There absolutely is no "enhanced" end users experience or gain by downloading the metadata in "advance" none nata zero.

Fix for akmods services is sent as Pull Request[0].

Johann, any further discussion about our decision to using systemd timer is irrelevant. We can't have Fedora without systemd. systemd.timer is part of base package which appears on all Fedora systems. It's not additional dependency. You can send your thoughts to devel.o. All commentaries about this decision here will be just ignored.


[0] https://github.com/rpm-software-management/dnf/pull/332

Please STOP HIJACKING THIS BUG! This bug is irrelevant with anykind of AKMOD package

Igor Gnatenko I dedicated over what 5 years of my live overseeing and handling conducting the most invasive change known in the project history. So big that even the projects own feature process was and still is not equipped to deal with a change of such magnitude, the replacement of it's init system ( you know the one called systemd and you continue to refer too ) and actually integrate it properly into the distribution not simply replace sys V with upstart like Casey did in 2008. One of the most hindrance as well as the number one reason that caused unneeded, unwanted and unknown breakage as a result of that work was incorrect dependency or even ( and this may come as a shock to you ) non existing dependency in package on components that make up the core/baseOS ( and even elsewhere ). 

Why because package maintainers where to incompetent to follow the fedora packaging guidelines. To you this might come as non trivial but for me it was quite a big deal since I lost significant hours of my life as an result of that incompetence chasing down and dealing with breakage which otherwise would have been easily discoverable and taken into account and prevented as well as others that where contributing to that effort including other individuals doing integration work, developers Fedora QA, proven packagers and FESCo.

I'm closing this bug with the actual resolution taking place here so Red Hat employees can just continue on their corporate path of Red Hat does what Red Hat wants to do in Fedora and gets away with it and they know it

Red Hat's DNF maintainers wont follow community approved Fedora packaging guidelines and adjust the packaging of their component accordingly but instead throw bullshit in contributors eyes as their excuse for several months as opposed to simply go to the length of changing the packaging guidelines should they not like what is written in it just like any other Red Hat employee has to do or collaborate with feature owners how best to go about integrating the component they maintain.

After all those guidelines are living documents. . .

(In reply to Jóhann B. Guðmundsson from comment #34)
> Red Hat's DNF maintainers wont follow community approved Fedora packaging
> guidelines and adjust the packaging of their component accordingly but
> instead throw bullshit in contributors eyes as their excuse for several
> months as opposed to simply go to the length of changing the packaging
> guidelines should they not like what is written in it just like any other
> Red Hat employee has to do or collaborate with feature owners how best to go
> about integrating the component they maintain.
Please note that I don't work for RedHat, I'm from Fedora community.

And you are not the individual that (In reply to Igor Gnatenko from comment #35)
> (In reply to Jóhann B. Guðmundsson from comment #34)
> > Red Hat's DNF maintainers wont follow community approved Fedora packaging
> > guidelines and adjust the packaging of their component accordingly but
> > instead throw bullshit in contributors eyes as their excuse for several
> > months as opposed to simply go to the length of changing the packaging
> > guidelines should they not like what is written in it just like any other
> > Red Hat employee has to do or collaborate with feature owners how best to go
> > about integrating the component they maintain.
> Please note that I don't work for RedHat, I'm from Fedora community.

I'm perfectly aware of the fact that you do not work for Red Hat as well as you have not contributed to the maintenance of the package in distribution and have non trivial changes to documentation and bash completion upstream.

Jóhann is right at least in 3rd point: it shouldn't be enabled by default, because it eats up download quota. Silently. Behind users back.

Igor can laught in chatrooms all he wants, but any feature, no matter how usefull it is, if it can deal material or any other damage should be on-demand.

Sadly, the only answer we'll get is, and i quote: "fork, if you don't like"

Yeah, that's what some housewife will do. Or she'll just install some other OS. And that's precisely why linux occupies such a small segment of desktop OSes.

Microsoft has taken it the next step in that evolution than is being done here.

In Windows 10 and on by default Microsoft's automatically downloads and install updates in addition to default commercial use of users' bandwidth to send updates to other MS users which is just equivalent of me waiting until someone fills his water supply then I'll drive a water truck to that someone's home, hooking it up to his water supply and start filling it up without his permission at his expense where he's either paying the water by the litre or on a flat rate. 

Anyway this bug was about preventing wasting or otherwise misuse other contributors time through poor package maintenance, That is a wastement of contributors life which they wont ever get back, which to me is more significant crime ( hence I overly anal about having people follow the guidelines ) since in the end money can be earned and more bandwith can be purchase but that time that got wasted you will never get back.

In previous Fedora version there was an option in order to avoid yum automatic downloads/updates when using a 3G connection and if I remember correctly this option was enabled by default.

I agree with Jóhann 3rd point: this should be not enabled by default, at least when using mobile connections and If it's not possible to change behavior based on connection type, please disable those timers until this specific issue fixed.

I can't say anything on the FPG issue (because I'm not an expert), but I would like to read an answer to comment #36.

Maybe we could split the bug: keeping this for the FPG issue an open another one for mobile connection behavior.

I agree with the point that this "feature" does not improve user experience.  3 out of 4 times I use dnf, I get this message:
Waiting for process with pid 1291 to finish.
And it takes a LONG TIME!  Yum was much faster even with updating metadata on the fly when invoked.  Yum seems to have been much more effecient at updating the metadata, and you could see the progress it was making since it did it on the fly.  With the dnf timers running in the background, you cannot see the progress.  Please go back to the yum behavior.

(In reply to Don Beusee from comment #40)

> did it on the fly.  With the dnf timers running in the background, you
> cannot see the progress.  Please go back to the yum behavior.

How about `tail -f /var/log/dnf.log` ?

Also please note, that makecache tries to synchronize, even if there is no internet connection via LAN

# grep "Failed to synchronize cache" /var/log/dnf.log*|wc -l
492

imho this shouldnt be default behavior and more criticaly default behaviour over metered connections

(In reply to Piotr Dobrogost from comment #41)
> (In reply to Don Beusee from comment #40)
> 
> > did it on the fly.  With the dnf timers running in the background, you
> > cannot see the progress.  Please go back to the yum behavior.
> 
> How about `tail -f /var/log/dnf.log` ?

Why should I have to do that?  The point everyone here is raising is that it should not be doing this in the background.  It creates complication you don't need, with no benefit to users (only problems - hangs because it's locked in the background, and using bandwidth for nothing - which users with metered connections can't afford, and possibly still out of date).  It makes no sense to do this in the background with no positive benefits and these negative side-affects.

I have to add to what @Don Beusee said (although I'm in favor of having background metadata refresh), that it *is* useless for the most part in RHEL 8.

Why - I have detailed in the post here: https://www.getpagespeed.com/server-setup/fixing-dnf-annoyances-in-centos-rhel-usability-or-bandwidth-choose-your-destiny

The dnf-makecache.timer is set to run every hour, while metadata_timer_sync DNF configuration is by default to *3 hours*.
This mix of things makes dnf-makecache run effectively no more often than every 3 hours. 

And considering that most repos' metadata is valid for 6 hours, the chances of having annoying metadata refresh when you run dnf interactively is more than 50% :)

Not completely useless, but getting close to it!