[Nut-upsuser] NUT no longer works after 2.7 -> 2.8 upgrade
Bill Gee
bgee at campercaver.net
Sat Dec 3 13:45:35 GMT 2022
Hi Simon -
Yes, I think that is a fair summary. We may have to revisit some of
this when the next Fedora 37 package for nut is released. In the
meantime I am getting what I want, which is a daily report of UPS status
in logwatch.
I do not use nut-monitor nor do I have any nut users. Those features
are not part of my use case. The system we have been working on is the
only system I have with nut installed, and it is the only system
protected by that particular UPS. All my other systems are protected by
APC UPSs and run apcupsd. I suppose someday I need to switch since
apcupsd has not seen any maintenance for many years.
Thank you for all your help. I hope this thread lives on somewhere so
that others can benefit. I think I saw bits and pieces of it in the
GitHub posts that Evgeny Klimek made a few days ago.
===============
Bill Gee
On 12/2/22 21:50, Simon Wilson via Nut-upsuser wrote:
> Aha!! Bingo, that resolved the issue for upsd. You may not have picked
> iut up Bill but the new "error" message shows it.
>
> Going back to your message from yesterday, upsd logged this:
> Dec 01 10:35:01 mythtv.billgee.local nut-server[3445]: fopen
> /var/run/upsd.pid: No such file or directory
> Dec 01 10:35:01 mythtv.billgee.local nut-server[3445]: Could not find
> PID file '/var/run/upsd.pid' to see if previous upsd instance is already
> running!
>
> With an environ.conf setting NUT_STATEPATH upsd logged this:
> Dec 02 10:11:18 mythtv.billgee.local nut-server[12675]: fopen
> /run/nut/upsd.pid: No such file or directory
> Dec 02 10:11:18 mythtv.billgee.local nut-server[12675]: Could not find
> PID file '/run/nut/upsd.pid' to see if previous upsd instance is already
> running!
>
> Note the difference - it is now looking in the CORRECT FOLDER /run/nut!
> There is not a pid there, that is fine - that pid check is to see if
> there is a upsd already running. Now it is pointing at a folder that nut
> can write too, that should work as designed. Awesome...
>
>
> So, I think I'm right in summarising as follows for Bill's situation:
>
> On Fedora / RH packages for 2.8.0
>
> * need to create a /usr/lib/tmpfiles.d/nut-client.conf which contains "D
> /run/nut 0770 root nut - -" to ensure the path exists for services which
> look for it (or edit the service files to point to nut-common.conf - but
> my preference is not to edit service files directly to prevent later
> breaks)
>
> * nut-driver
> -- setting/uncommenting STATEPATH in upsd.conf to /var/run/nut or
> /run/nut as the *only* fix does NOT allow driver to start - it still
> tries to go to /var/run (this one I am not 100% sure of from looking
> back through the thread, but I *think* is correct)
> -- can be fixed by dropping in a service.d/ drop-in file which sets
> Environment=NUT_STATEPATH=/run/nut
>
> * nut-server
> -- setting STATEPATH in upsd.conf to /var/run/nut or /run/nut **does**
> allow server to start (unlike the driver)
> -- can also be fixed by dropping in a service.d/ drop-in file which sets
> Environment=NUT_STATEPATH=/run/nut
> -- the drop-in is a better fix than uncommenting/setting STATEPATH, as
> it makes upsd look in the correct folder for all of its pid tests
>
>
>
> Bill, have I summarised those correctly?
>
> It would seem that using drop-in files to set NUT_STATEPATH for both
> upsdrvctl (nut-driver) and upsd (nut-server) is probably the best
> short-term fix.
>
>
> What is curious is the variation between packages and OSs though.
> - For Bill on F37 all the above fixes were needed - nut-client.conf, and
> both nut-driver and nut-server needed fixing for STATEPATH, with two x
> drop-in files.
> - For me on RHEL8.7 (which comes with a working 2.7.4 btw, so I'm my own
> worst enemy there), installing the available 2.8.0-1.el8 package was
> broken, but I only needed to fix the nut-client.conf issue, I did not
> need to uncomment STATEPATH in upsd.conf or add drop-in files to set
> NUT_STATEPATH - and driver and server both start fine, looking in /run/nut.
>
> Bill, you should now have a fully working nut stack. I assume you have
> configured users and got nut-monitor working?
>
> Simon
>
> ----- Message from Bill Gee <bgee at campercaver.net> ---------
> Date: Fri, 2 Dec 2022 10:19:20 -0600
> From: Bill Gee <bgee at campercaver.net>
> Subject: Re: [Nut-upsuser] NUT no longer works after 2.7 -> 2.8 upgrade
> To: nut-upsuser at alioth-lists.debian.net
>
>
>> Oops, sorry about missing your test two. I did not read it all the
>> way through.
>>
>> That test is done, and nut-server starts successfully. Upsc will give
>> back information about the device. I did have to run a daemon-reload.
>> It does complain about not finding the PID file.
>>
>> =================================
>> [root at mythtv ups]# cat
>> /etc/systemd/system/nut-server.service.d/environ.conf
>> [Service]
>> Environment=NUT_STATEPATH=/run/nut
>> [root at mythtv ups]# cat
>> /etc/systemd/system/nut-driver at .service.d/environ.conf
>> [Service]
>> Environment=NUT_STATEPATH=/run/nut
>>
>> [root at mythtv ups]# systemctl --full --no-pager status nut-server
>> ● nut-server.service - Network UPS Tools - power devices information
>> server
>> Loaded: loaded (/usr/lib/systemd/system/nut-server.service;
>> enabled; preset: disabled)
>> Drop-In: /etc/systemd/system/nut-server.service.d
>> └─environ.conf
>> Active: active (running) since Fri 2022-12-02 10:11:18 CST; 9s ago
>> Main PID: 12675 (upsd)
>> Tasks: 1 (limit: 9482)
>> Memory: 732.0K
>> CPU: 5ms
>> CGroup: /system.slice/nut-server.service
>> └─12675 /usr/sbin/upsd -F
>>
>> Dec 02 10:11:18 mythtv.billgee.local nut-server[12675]: fopen
>> /run/nut/upsd.pid: No such file or directory
>> Dec 02 10:11:18 mythtv.billgee.local nut-server[12675]: Could not find
>> PID file '/run/nut/upsd.pid' to see if previous upsd instance is
>> already running!
>> Dec 02 10:11:18 mythtv.billgee.local nut-server[12675]: listening on
>> ::1 port 3493
>> Dec 02 10:11:18 mythtv.billgee.local nut-server[12675]: listening on
>> 127.0.0.1 port 3493
>> Dec 02 10:11:18 mythtv.billgee.local upsd[12675]: listening on ::1
>> port 3493
>> Dec 02 10:11:18 mythtv.billgee.local upsd[12675]: listening on
>> 127.0.0.1 port 3493
>> Dec 02 10:11:18 mythtv.billgee.local nut-server[12675]: Connected to
>> UPS [cyberpower]: usbhid-ups-cyberpower
>> Dec 02 10:11:18 mythtv.billgee.local upsd[12675]: Connected to UPS
>> [cyberpower]: usbhid-ups-cyberpower
>> Dec 02 10:11:18 mythtv.billgee.local upsd[12675]: Running as
>> foreground process, not saving a PID file
>> Dec 02 10:11:18 mythtv.billgee.local nut-server[12675]: Running as
>> foreground process, not saving a PID file
>> =============================
>>
>> ===============
>> Bill Gee
>>
>> On 12/2/22 06:24, Simon Wilson via Nut-upsuser wrote:
>>> Hi Bill,
>>>
>>> OK your test 1 and 2 line up with my ask for test 1 :)
>>>
>>> Have another read of the Test 2 ask please if you can:
>>>
>>>>> 2. Second test:- copy the edited
>>>>> /etc/systemd/system/nut-driver at .service.d/environ.conf to
>>>>> /etc/systemd/system/nut-server.service.d/environ.conf. So you
>>>>> should at that point have both locations with a file saying
>>>>> [Service]
>>>>> Environment=NUT_STATEPATH=/run/nut
>>>>> Then comment out STATEPATH line (back to default) in upsd.conf and
>>>>> restart nut-server - does it still start, and does it still pop a
>>>>> "Could not find PID file '/var/run/upsd.pid'" message? That tests
>>>>> whether the drop-in file is a better, more consistent fix for now
>>>>> (until the packages are resolved). Calling the nut-server process
>>>>> with that variable set for upsd *even before it reads upsd.conf*
>>>>> may remove the first error 'Could not find PID file
>>>>> '/var/run/upsd.pid''
>>>
>>> Your test 3 and 4 are not quite what is needed, unless you did copy
>>> the environ.conf file into /etc/systemd/system/nut-server.service.d/
>>> but didn't say so?
>>>
>>> Could you please copy your nut-driver's environ.conf file to
>>> /etc/systemd/system/nut-server.service.d/ THEN comment out the
>>> STATEPATH line and see if nut-server starts.
>>>
>>> Why am I asking this>
>>> At the moment you are using one fix to resolve the driver (an
>>> environ.conf file) and a different fix to get nut-server going
>>> (STATEPATH). Trying to see if one fix (the environ.conf file fix)
>>> will resolve both driver and server, and in doing so also get rid of
>>> the error message 'Could not find PID file '/var/run/upsd.pid''.
>>>
>>> Simon
>>>
>>> ----- Message from Bill Gee <bgee at campercaver.net> ---------
>>> Date: Fri, 2 Dec 2022 06:07:20 -0600
>>> From: Bill Gee <bgee at campercaver.net>
>>> Subject: Re: [Nut-upsuser] NUT no longer works after 2.7 -> 2.8 upgrade
>>> To: nut-upsuser at alioth-lists.debian.net
>>>
>>>
>>>> Test 1 - I moved the environ.conf file to /tmp. I ran systemctl
>>>> daemon-reload, then restarted nut-driver at cyberpower.service. Results:
>>>>
>>>> =====================================
>>>> [root at mythtv nut-driver at .service.d]# systemctl restart
>>>> nut-driver at cyberpower.service
>>>> Job for nut-driver at cyberpower.service failed because the control
>>>> process exited with error code.
>>>> See "systemctl status nut-driver at cyberpower.service" and "journalctl
>>>> -xeu nut-driver at cyberpower.service" for details.
>>>> [root at mythtv nut-driver at .service.d]# systemctl --full --no-pager
>>>> status nut-driver at cyberpower.service
>>>> ● nut-driver at cyberpower.service - Network UPS Tools - device driver
>>>> for NUT device 'cyberpower'
>>>> Loaded: loaded (/usr/lib/systemd/system/nut-driver at .service;
>>>> enabled; preset: disabled)
>>>> Drop-In: /etc/systemd/system/nut-driver at cyberpower.service.d
>>>> └─nut-driver-enumerator-generated-checksum.conf,
>>>> nut-driver-enumerator-generated.conf
>>>> Active: activating (auto-restart) (Result: exit-code) since Fri
>>>> 2022-12-02 05:54:03 CST; 2s ago
>>>> Process: 10732 ExecStartPre=/usr/bin/systemd-tmpfiles --create
>>>> /usr/lib/tmpfiles.d/nut-client.conf (code=exited, status=0/SUCCESS)
>>>> Process: 10733 ExecStart=/bin/sh -c
>>>> NUTDEV="`/usr/libexec/nut-driver-enumerator.sh
>>>> --get-device-for-service cyberpower`" && [ -n "$NUTDEV" ] || { echo
>>>> "FATAL: Could not find a NUT device section for service unit
>>>> cyberpower" >&2 ; exit 1 ; } ; /usr/sbin/upsdrvctl start "$NUTDEV"
>>>> (code=exited, status=1/FAILURE)
>>>> CPU: 80ms
>>>> =========================================
>>>>
>>>> It seems that the nut device driver requires environ.conf to be
>>>> present.
>>>>
>>>> Test 2 - I moved environ.conf back to the correct place. I edited
>>>> the file to use "Environment=NUT_STATEPATH=/run/nut". I did a
>>>> daemon-reload then started the nut-driver. It worked - no errors.
>>>>
>>>> Test 3 - I modified /etc/ups/upsd.conf to comment out the STATEPATH
>>>> line. I restarted nut-server.service. It failed.
>>>>
>>>> ================================
>>>> [root at mythtv ups]# systemctl --full --no-pager status nut-server
>>>> ● nut-server.service - Network UPS Tools - power devices information
>>>> server
>>>> Loaded: loaded (/usr/lib/systemd/system/nut-server.service;
>>>> enabled; preset: disabled)
>>>> Active: active (running) since Fri 2022-12-02 06:00:54 CST; 13s
>>>> ago
>>>> Main PID: 11452 (upsd)
>>>> Tasks: 1 (limit: 9482)
>>>> Memory: 728.0K
>>>> CPU: 5ms
>>>> CGroup: /system.slice/nut-server.service
>>>> └─11452 /usr/sbin/upsd -F
>>>>
>>>> Dec 02 06:00:54 mythtv.billgee.local nut-server[11452]: listening on
>>>> ::1 port 3493
>>>> Dec 02 06:00:54 mythtv.billgee.local nut-server[11452]: listening on
>>>> 127.0.0.1 port 3493
>>>> Dec 02 06:00:54 mythtv.billgee.local upsd[11452]: listening on ::1
>>>> port 3493
>>>> Dec 02 06:00:54 mythtv.billgee.local upsd[11452]: listening on
>>>> 127.0.0.1 port 3493
>>>> Dec 02 06:00:54 mythtv.billgee.local nut-server[11452]: /var/run is
>>>> world readable
>>>> Dec 02 06:00:54 mythtv.billgee.local upsd[11452]: /var/run is world
>>>> readable
>>>> Dec 02 06:00:54 mythtv.billgee.local upsd[11452]: Can't connect to
>>>> UPS [cyberpower] (usbhid-ups-cyberpower): No such file or directory
>>>> Dec 02 06:00:54 mythtv.billgee.local nut-server[11452]: Can't
>>>> connect to UPS [cyberpower] (usbhid-ups-cyberpower): No such file or
>>>> directory
>>>> Dec 02 06:00:54 mythtv.billgee.local nut-server[11452]: Running as
>>>> foreground process, not saving a PID file
>>>> Dec 02 06:00:54 mythtv.billgee.local upsd[11452]: Running as
>>>> foreground process, not saving a PID file
>>>> ===================================
>>>>
>>>> Test 4 - I uncommented the STATEPATH line in upsd.conf. It points
>>>> to /run/nut. I restarted nut-server. Success.
>>>>
>>>>
>>>> ===============
>>>> Bill Gee
>>>>
>>>> On 12/1/22 18:35, Simon Wilson via Nut-upsuser wrote:
>>>>> Resending as original was too big for list acceptance.
>>>>>
>>>>> Hi Bill,
>>>>>
>>>>> /etc/systemd/system/nut-driver at .service.d/environ.conf sets the
>>>>> nut-driver service's environment variable, such that it sees a
>>>>> workable NUT_STATEPATH of /var/run/nut when upsdrvctl is run by the
>>>>> service, regardless of what is set in upsd.conf, and explains why
>>>>> the driver worked yesterday but upsd didn't.
>>>>>
>>>>> Tests which may be interesting:
>>>>>
>>>>> 1. First test:- move nut-driver's environ.conf file to somewhere
>>>>> else temporarily; leave upsd.conf STATEPATH uncommented saying
>>>>> /run/nut; restart nut-driver at cyberpower.service; and see if it
>>>>> runs. This tests to see if it *needs* the drop-in service file *or*
>>>>> will work with only STATEPATH explicitly set in upsd.conf to
>>>>> /run/nut. If this prevents the driver from working, put the
>>>>> environ.conf file back (but edit it, it should say /run/nut, not
>>>>> /var/run/nut)
>>>>>
>>>>> 2. Second test:- copy the edited
>>>>> /etc/systemd/system/nut-driver at .service.d/environ.conf to
>>>>> /etc/systemd/system/nut-server.service.d/environ.conf. So you
>>>>> should at that point have both locations with a file saying
>>>>> [Service]
>>>>> Environment=NUT_STATEPATH=/run/nut
>>>>> Then comment out STATEPATH line (back to default) in upsd.conf and
>>>>> restart nut-server - does it still start, and does it still pop a
>>>>> "Could not find PID file '/var/run/upsd.pid'" message? That tests
>>>>> whether the drop-in file is a better, more consistent fix for now
>>>>> (until the packages are resolved). Calling the nut-server process
>>>>> with that variable set for upsd *even before it reads upsd.conf*
>>>>> may remove the first error 'Could not find PID file
>>>>> '/var/run/upsd.pid''
>>>>>
>>>>> And definitely document any changes you make to your setup as
>>>>> subsequent package releases will likely change all of this :)
>>>>>
>>>>> Couple more comments inline below.
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>> ----- Message from Bill Gee <bgee at campercaver.net> ---------
>>>>> Date: Thu, 1 Dec 2022 16:49:14 -0600
>>>>> From: Bill Gee <bgee at campercaver.net>
>>>>> Subject: Re: [Nut-upsuser] NUT no longer works after 2.7 -> 2.8
>>>>> upgrade
>>>>> To: nut-upsuser at alioth-lists.debian.net
>>>>>
>>>>>> Checking now - There is a file called
>>>>>> /etc/systemd/system/nut-driver at .service.d/environ.conf. Its
>>>>>> contents are
>>>>>>
>>>>>> ==========================
>>>>>> [root at mythtv nut-driver at .service.d]# ll
>>>>>> total 8
>>>>>> -rw-r--r-- 1 root root 49 Nov 29 18:14 environ.conf
>>>>>> -rw-r--r-- 1 root root 81 Nov 30 18:58
>>>>>> nut-driver-enumerator-generated-checksum.conf
>>>>>>
>>>>>> [root at mythtv nut-driver at .service.d]# cat environ.conf
>>>>>> [Service]
>>>>
>>>> [snip]
>>>>
>>>> _______________________________________________
>>>> Nut-upsuser mailing list
>>>> Nut-upsuser at alioth-lists.debian.net
>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>>
>>>
>>> ----- End message from Bill Gee <bgee at campercaver.net> -----
>>>
>>>
>>>
>>
>> _______________________________________________
>> Nut-upsuser mailing list
>> Nut-upsuser at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
>
> ----- End message from Bill Gee <bgee at campercaver.net> -----
>
>
>
More information about the Nut-upsuser
mailing list