Created attachment 1934552 [details] nut.spec patch to fix issues mentioned in bug Description of problem: - nut-client.rpm is missing nut.target, required to enable nut-monitor.service - nut-client.rpm missing nut.conf - nut.rpm contains upslog, which belongs in nut-client.rpm - nut.rpm missing tmpfiles.d/nut-common.conf Version-Release number of selected component (if applicable): nut-2.8.0-7 nut-client-2.8.0-7 How reproducible: On install of packages Steps to Reproduce: 1a. install nut.rpm (without nut-client.rpm) 2a. /run/nut is not created 1b. install nut-client.rpm (without nut.rpm) 2b. /usr/bin/upslog missing (client program) 3b. /etc/ups/nut.conf missing for nut-monitor.service 4b. systemctl enable nut-monitor fails to enable service (nut.target doesn't exist) Errors are all in nut.spec file (not part of upstream). I've attached a patch to nut.spec which fixes all these problems... (also brings it in sync with the Debian client package) NOTE: tried forking src.fedoraproject.org/rpms/nut to create a pull request, but couldn't push to my fork even with a API-KEY... guess that's not possible? Alt. solution is to create a nut-common.rpm, but for just a few files it seemed a little overkill... packaging guidelines allow for duplicate pkg file ownership if they are identical and from same SRPM.
FEDORA-2023-7552b18058 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-7552b18058
FEDORA-2023-7552b18058 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-7552b18058` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-7552b18058 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-7552b18058 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
Hi I have 2.8.0-8.fc37 installed, but I am afraid nut-monitor doesn't start on reboot after enabling it. I have to manually start nut-monitor for the service to become active. I expect enabling the nut-monitor service that it should become active and survive reboots. systemctl enable nut-monitor systemctl status nut-monitor ○ nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller Loaded: loaded (/usr/lib/systemd/system/nut-monitor.service; enabled; preset: disabled) Active: inactive (dead) systemctl start nut-monitor systemctl status nut-monitor ● nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller Loaded: loaded (/usr/lib/systemd/system/nut-monitor.service; enabled; preset: disabled) Active: active (running) since Wed 2023-02-08 20:17:03 GMT; 2s ago Process: 8363 ExecStartPre=/usr/bin/systemd-tmpfiles --create /usr/lib/tmpfiles.d/nut-com> Main PID: 8364 (upsmon) Tasks: 2 (limit: 18355) Memory: 1.3M CPU: 9ms CGroup: /system.slice/nut-monitor.service ├─8364 /usr/sbin/upsmon -F └─8365 /usr/sbin/upsmon -F systemd[1]: Starting nut-monitor.service - Network UPS Tools - power systemd[1]: Started nut-monitor.service - Network UPS Tools - power nut-monitor[8364]: fopen /run/nut/upsmon.pid: No such file or direct nut-monitor[8364]: Could not find PID file to see if previous upsmon nut-monitor[8364]: UPS: ups@myserver (secondary) (power value 1) nut-monitor[8364]: Using power down flag file /etc/killpower Rich
(In reply to Richard Booth from comment #4) > Hi > > I have 2.8.0-8.fc37 installed, but I am afraid nut-monitor doesn't start on > reboot after enabling it. I have to manually start nut-monitor for the > service to become active. I expect enabling the nut-monitor service that it > should become active and survive reboots. > > systemctl enable nut-monitor > systemctl status nut-monitor Richard, this is by design and part of the upstream behavior... enabling nut-monitor only enables the service as part of the nut.target (run systemctl cat nut-monitor to see the "WantedBy" line). To have the service start on boot, you need to run `systemctl enable nut.target` ... and yes, it'd probably be nice if there was a README installed with nut-client that explained that :)
Thank you Scott. It is now running on boot. :) Much appreciated. Rich
I don't think this has been fully addressed, in particular: - nut-client.rpm is missing nut.target, required to enable nut-monitor.service On a system with just nut-client installed, nut.target is not present so you cannot enable it: # systemctl enable nut.target Failed to enable unit: Unit file nut.target does not exist. Fixes for this also need to make it to EPEL. I'm not sure why this seemed to be working previously just recently, but it isn't working now.
My bad for suggesting removing it in https://src.fedoraproject.org/rpms/nut/pull-request/14
fedora 37 is eol, changing version to 38 pull request merged
Michal - we also need to get this fixed in epel9/epel8 - but they have diverged a lot from Fedora so not quite sure the best was to update them.
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. 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 'version' of '38'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Should I close, or does this need to be re-assigned to EPEL?
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 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 Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.