| Summary: | systemd service too greedy | ||
|---|---|---|---|
| Product: | Fedora | Reporter: | Piergiorgio Sartor <piergiorgio.sartor> |
| Component: | akmods | Assignee: | Richard <hobbes1069> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | kwizart |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Hardware: | x86_64 | ||
| OS: | GNU/Linux | ||
| namespace: | |||
|
Description
Piergiorgio Sartor
2012-12-02 00:46:23 CET
patch welcomed Hi Nicolas, actually, I think I've a further problem. I mount /usr on separate partition as "ro". Since F-17, /lib, /bin and /sbin are link into the respective /usr folders. Which means /lib/modules is "ro" per default, with this setup. I guess "akmods" will never work at boot, since it will not be able to install a kernel module. Am I right or wrong? At the moment I disabled "akmods.service" for this reason. bye, pg As far as the amount of time it takes to complete you have to be careful interpreting the results. It is not actual CPU time but wall clock time. Much of the time can be it waiting on something else.... As far as mounting /usr as "ro" that's not really a supported use case. How do you expect to even do a "yum update"? You are asking for competing things. If you need /usr to be "ro" then you're likely working with an "appliance" that does not get updated frequently. In that case it's not a valid expectation to have the drivers updated frequently. You should run akmods manually when you do updates. Hi, well, about the amount of time, I just reported what "systemd-analyze" shows. About the "yum update", of course, when doing it, I remount "/usr" with "rw", but that's because I control the update process. In this case, if the kernel is updated, "akmods" has no problems. The issue happens in case a module is updated, probably if an old kernel is booted, not sure. Anyway, this is another issue, just one more reason to disable the service, for me. Thanks, bye, pg Thanks for the prompt response. Since I don't think this is a use case we can support I'm closing the bug but please reopen if you have more information or patches at a later date. Hi Richard, what does it mean "it is not a supported use case"? Optimizing the huge amount of time akmods need is not a "supported use case"? The story of /usr it is just my problem, I used it to mention I should disable akmods anyway, it has nothing to do with this report. The fact that akmods.service seems to use quite a lot of time, seems to me a point for improvement. If your not sure about the reason, we could make a note in this report and, when resources will be available, have a look into it. Thanks for understanding, bye, pg (In reply to comment #6) > Hi Richard, > > what does it mean "it is not a supported use case"? > > Optimizing the huge amount of time akmods need is not a "supported use case"? What I mean is that the "time" is wall clock time. As far as a performance metric it's almost useless. Just because something takes some time doesn't mean there's anything wrong. On a side note systemd-analyze blame says it takes about 22 seconds on my system and about the same amount of time the dkms service takes. But running akmods as root when you don't need to rebuild a module takes less than a second. > The fact that akmods.service seems to use quite a lot of time, seems to me a > point for improvement. Being slow (if that is in fact the case) is not a bug. What you're talking about is a request for enhancement (RFE) which I simply don't have time to do, but as Nicolas mentioned, patches are welcomed. > If your not sure about the reason, we could make a note in this report and, > when resources will be available, have a look into it. Since every is volunteering their type (no one is paid to work on RPM Fusion as far as I know) "resources" is not a simple matter. RPMFusion is no longer releasing updates for this version of Fedora. This bug will be set to RESOLVED:EXPIRED next week to reflect this. If the problem persists after upgrading to the latest version of Fedora, please update the version field of this bug (and re-open it if it has been closed). My sum-up of this issue would be: The reported problem is that akmods, even if it doesn't have a kmod to build takes a lot of time. -> We need to investigate if akmods.service isn't started at a time it doesn't have every resources it needs. Or wait for a ressources that will be activated later. Also the reporter mentioned that usually, the system is mounted ro, so we could have exited even earlier. The other consequence of such use case is that the best time for akmod to build/install the kmod is during the yum/rpm transaction. We would be to start building as soon as the kernel-devel is in place, then install at the end of the %posttrans. @Piergiorgio With the above said, you are still welcomed to provide patches based on theses issues. http://cvs.rpmfusion.org/viewvc/rpms/akmods/devel/?root=free I don't see any reason to keep this bug open. Wall clock time is not a useful metric and if there's nothing to build running takes almost no "real" time so I doubt the service completion time is anywhere near 10 seconds. |