Bug 2156504 - nut.spec: nut-monitor enable fails, nut.conf missing, upslog in wrong pkg
Summary: nut.spec: nut-monitor enable fails, nut.conf missing, upslog in wrong pkg
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: nut
Version: 38
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Michal Hlavinka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-12-27 06:33 UTC by Scott Shambarger
Modified: 2024-05-21 14:24 UTC (History)
6 users (show)

Fixed In Version: nut-2.8.0-8.fc38 nut-2.8.0-8.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-05-21 14:24:39 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
nut.spec patch to fix issues mentioned in bug (1.86 KB, patch)
2022-12-27 06:33 UTC, Scott Shambarger
no flags Details | Diff

Description Scott Shambarger 2022-12-27 06:33:17 UTC
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.

Comment 1 Fedora Update System 2023-01-18 22:14:51 UTC
FEDORA-2023-7552b18058 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-7552b18058

Comment 2 Fedora Update System 2023-01-19 23:59:49 UTC
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.

Comment 3 Fedora Update System 2023-01-27 08:55:58 UTC
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.

Comment 4 Richard Booth 2023-02-08 20:26:20 UTC
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

Comment 5 Scott Shambarger 2023-02-08 22:05:35 UTC
(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 :)

Comment 6 Richard Booth 2023-02-08 23:13:42 UTC
Thank you Scott. It is now running on boot. :) Much appreciated. 

Rich

Comment 7 Orion Poplawski 2023-11-30 18:37:13 UTC
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.

Comment 8 Orion Poplawski 2023-11-30 18:51:37 UTC
My bad for suggesting removing it in https://src.fedoraproject.org/rpms/nut/pull-request/14

Comment 9 Michal Hlavinka 2023-12-05 23:11:24 UTC
fedora 37 is eol, changing version to 38
pull request merged

Comment 10 Orion Poplawski 2023-12-06 15:11:47 UTC
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.

Comment 11 Aoife Moloney 2024-05-07 15:54:30 UTC
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.

Comment 12 Scott Shambarger 2024-05-07 22:37:08 UTC
Should I close, or does this need to be re-assigned to EPEL?

Comment 13 Aoife Moloney 2024-05-21 14:24:39 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.