| Summary: | Add systemd preset file to allow specific services to be enabled by default | ||
|---|---|---|---|
| Product: | Fedora | Reporter: | Richard <hobbes1069> |
| Component: | rpmfusion-free-release | Assignee: | Nicolas Chauvet <kwizart> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | nerijus, orion |
| Priority: | P5 | ||
| Version: | 22 | ||
| Hardware: | All | ||
| OS: | GNU/Linux | ||
| namespace: | |||
|
Description
Richard
2015-07-15 05:01:13 CEST
I forgot to add some background which has been discussed on the mailing list. It appears that systemd will now ignore attempts to enable a service from RPM scipts (i.e. %post) and will only enable a service by default using a preset file http://www.freedesktop.org/software/systemd/man/systemd.preset.html I don't understand what prevent akmods to bundle it's own preset ? Another way would be to make the akmods script static so it's only enabled on a special event. (In reply to comment #2) > I don't understand what prevent akmods to bundle it's own preset ? It could, but that's directly counter to the recommendation to have a distro specific file. It would also keep us consistent with Fedora which packages the presets in the fedora-release package. > Another way would be to make the akmods script static so it's only enabled on a > special event. I don't disagree but I don't know of another mechanism. Did you have one in mind? (In reply to comment #3) > (In reply to comment #2) > > I don't understand what prevent akmods to bundle it's own preset ? > > It could, but that's directly counter to the recommendation to have a distro > specific file. It would also keep us consistent with Fedora which packages the > presets in the fedora-release package. This do not apply to us, we are a meta repository, not a distro (In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > I don't understand what prevent akmods to bundle it's own preset ? > > > > It could, but that's directly counter to the recommendation to have a distro > > specific file. It would also keep us consistent with Fedora which packages the > > presets in the fedora-release package. > This do not apply to us, we are a meta repository, not a distro True, but it would be consistent. If you're not worried about packages shipping their own preset files then I guess it's not a big deal. An alternative method would be to use rpmfusion-free-presets with the preset and have the akmod package to require system-free-presets so any others downstream remix would be allowed to have an alternative default preset for the whole free section. But that's seem a big hammer. Another way would be to have the akmods enablement preset to be provided by fedora itslef. I don't know if that can be acceptable. But above all, I want to keep rpmfusion-free-release clean from other purpose than what it already has. In order to only have limited changes to it (if no change at all within a given release). (In reply to comment #6) > An alternative method would be to use rpmfusion-free-presets with the preset > and have the akmod package to require system-free-presets so any others > downstream remix would be allowed to have an alternative default preset for the > whole free section. > But that's seem a big hammer. While the package would go in the free repository I'm not sure it needs to be in the name... Would we have rpmfusion-nonfree-presets? I'm thinking something like rpmfusion-systemd-presets would work and better convey the purpose. > Another way would be to have the akmods enablement preset to be provided by > fedora itslef. I don't know if that can be acceptable. I would rather handle this within RPM Fusion regardless of FESCO's probability of accepting the request but I can try if that's where we want to start. (In reply to comment #7) > But above all, I want to keep rpmfusion-free-release clean from other purpose > than what it already has. In order to only have limited changes to it (if no > change at all within a given release). It's not something that would change very often... I wonder how many systemd services are even provided by RPM Fusion? But I understand your concern. Ok, here's the list of packages in RPM Fusion that provide service file:
# repoquery --disablerepo=* --enablerepo=rpmfusion-{free,nonfree} --whatprovides "*.service"
mythtv-backend-0:0.27.4-2.fc21.x86_64
xorg-x11-drv-nvidia-cuda-1:343.22-3.fc21.x86_64
mpd-1:0.19.2-1.fc21.x86_64
akmods-0:0.5.1-4.fc21.noarch
VirtualBox-guest-0:4.3.20-1.fc21.x86_64
minidlna-0:1.1.4-3.fc21.x86_64
vagalume-0:0.8.5-5.fc21.x86_64
mate-applet-streamer-0:0.1.2-2.fc21.x86_64
motion-0:3.3.0.trunkREV557-9.fc21.x86_64
I probably could have crafted the query to capture updates but I don't think any have been added since F21 released?
I have added a preset file to the akmods package for the time being but I still think a method of handling this at the repository level would be preferred. FWIW - EPEL does the same thing in epel-release. Is "enable akmods-shutdown.service" really needed? Here it runs on every shutdown and takes 1 min 30 sec every time. Probably tries to build nvidia module, but I don't know why, because it is built already. (In reply to comment #12) > Is "enable akmods-shutdown.service" really needed? Here it runs on every > shutdown and takes 1 min 30 sec every time. Probably tries to build nvidia > module, but I don't know why, because it is built already. It's only purpose is to give you another opportunity to build a kmod package for transient issues. Obviously it will not help in the case of compile failure. If it's actually taking that long, do you have a akmod build that's failing? Do you actually see the run taking that long or are you relying on systemd-analyze? (In reply to comment #13) > It's only purpose is to give you another opportunity to build a kmod package > for transient issues. Obviously it will not help in the case of compile > failure. If it's actually taking that long, do you have a akmod build that's > failing? Do you actually see the run taking that long or are you relying on > systemd-analyze? I don't think it fails, as I have the module built, the driver works and I don't update kernel before shutdown. I see the run taking 1 min 30 sec, and then it continues to shutdown. I don't know how to check if the build is failing or what is happening. If I run /usr/sbin/akmods-shutdown manually I get: # /usr/sbin/akmods-shutdown Building modules for all installed kernels. Checking kmods exist for 4.2.3-300.fc23.i686 [ OK ] Checking kmods exist for 4.2.5-300.fc23.i686 [ OK ] Checking kmods exist for 4.2.6-300.fc23.i686 [ OK ] (In reply to comment #15) > If I run /usr/sbin/akmods-shutdown manually I get: > # /usr/sbin/akmods-shutdown > Building modules for all installed kernels. > Checking kmods exist for 4.2.3-300.fc23.i686 [ OK ] > Checking kmods exist for 4.2.5-300.fc23.i686 [ OK ] > Checking kmods exist for 4.2.6-300.fc23.i686 [ OK ] Ok, I don't think it's actually taking that long because we have to use a trick to make it run on shutdown. The startup command is actually /usr/bin/true, it doesn't actually run akmods until it gets to the ExecStop after shutdown has been initiated. So systemd thinks it's doing something when it's not. More than likely other parallel processes are running/stoping. Worst case you can disable it if you don't find it helpful. (In reply to comment #16) > Worst case you can disable it if you don't find it helpful. That's why I proposed to disable it by default, because it pauses reboot every time for 1.5 mins here. BTW, it writes to the shutdown console when shutting down that it will run this job for no more 1 min 30 sec. And F23 here. (In reply to comment #17) > (In reply to comment #16) > > Worst case you can disable it if you don't find it helpful. > > That's why I proposed to disable it by default, because it pauses reboot every > time for 1.5 mins here. I'm hesitant to change things without understanding what's going on. I'm on F22 and my shutdown does not "hang". Can you check out /var/cache/akmods/akmods.log and see if it shows anything? It has timestamps so if it's actually doing something for that long it should say. Also, what is the output of "systemctl status akmods-shutdown"? # systemctl status akmods-shutdown -l ● akmods-shutdown.service - Builds and install new kmods from akmod packages Loaded: loaded (/usr/lib/systemd/system/akmods-shutdown.service; disabled; vendor preset: enabled) Active: active (exited) since Pr 2015-11-16 00:20:39 EET; 1 day 22h ago Main PID: 648 (code=exited, status=0/SUCCESS) CGroup: /system.slice/akmods-shutdown.service Lap 16 00:20:38 localhost.localdomain systemd[1]: Starting Builds and install new kmods from akmod packages... Lap 16 00:20:39 localhost.localdomain systemd[1]: Started Builds and install new kmods from akmod packages. # uptime 23:17:44 up 1 day, 22:57, 3 users, load average: 0,61, 0,48, 0,33 # date An Lap 17 23:17:54 EET 2015 /var/cache/akmods/akmods.log - http://paste.fedoraproject.org/291601/44779510 # ls -l /var/cache/akmods/nvidia-304xx viso 9124 -rw-r--r--. 1 root root 349182 2015-11-08 22:03 304.128-2-for-4.2.5-300.fc23.i686.log -rw-r--r--. 1 root root 349136 2015-11-12 10:55 304.128-2-for-4.2.6-300.fc23.i686.log -rw-r--r--. 1 root root 3769942 2015-11-08 22:03 kmod-nvidia-304xx-4.2.5-300.fc23.i686-304.128-2.fc23.i686.rpm -rw-r--r--. 1 root root 3771242 2015-11-12 10:55 kmod-nvidia-304xx-4.2.6-300.fc23.i686-304.128-2.fc23.i686.rpm -rw-r--r--. 1 root root 1091934 2015-11-12 10:55 nvidia-304xx-kmod-debuginfo-304.128-2.fc23.i686.rpm /var/cache/akmods/nvidia-304xx/.last.log - http://paste.fedoraproject.org/291602/47795207 It seems it was killed at installing kmod-nvidia-304xx-4.2.3-300.fc23.i686, as the last line is Diegiama (translates Installing), while the last lines of 304.128-2-for-4.2.6-300.fc23.i686.log are: Diegiama : kmod-nvidia-304xx-4.2.6-300.fc23.i686-304.128-2.fc2 1/1 Tikrinama : kmod-nvidia-304xx-4.2.6-300.fc23.i686-304.128-2.fc2 1/1 Įdiegta: kmod-nvidia-304xx-4.2.6-300.fc23.i686.i686 304.128-2.fc23 Baigta! 2015/11/12 10:55:12 akmods: Successful. |