similar to: NUT on Linux, pid related errors

On Jul 30, 2013, at 1:36 PM, Kris Jordan wrote: > upsd removes its pid files when it's stopped, upsmon does not. Hmm, interesting observation. Offhand, I think both should remove the PID files, but the way that upsmon drops root privileges might make this difficult. > If I remove upsmon's manually after stopping it, I get a different message for it when I start it back up... >

Charles Lepple wrote, On 7/31/2013 6:04 AM: > On Jul 30, 2013, at 1:36 PM, Kris Jordan wrote: > >> upsd removes its pid files when it's stopped, upsmon does not. > Hmm, interesting observation. Offhand, I think both should remove the PID files, but the way that upsmon drops root privileges might make this difficult. Makes sense. The manual says, --with-pidpath=PATH Changes the

On Aug 1, 2013, at 1:34 AM, Kris Jordan wrote: > The kill error is coming from this line: > https://github.com/networkupstools/nut/blob/master/common/common.c#L263 > > Which is called from: > https://github.com/networkupstools/nut/blob/master/client/upsmon.c#L1930 > > In which case would you need to "see if this is going to work first"? Agreed, the first

I deleted the plist file and rebooted: sudo /sw/sbin/upsmon -D Network UPS Tools upsmon 2.7.4 0.000000 fopen /sw/var/run/upsmon.pid: No such file or directory 0.044649 UPS: ups at ip address (slave) (power value 1) 0.081597 Using power down flag file /etc/killpower 0.162720 debug level is '1' 0.538410 Trying to connect to UPS [ups at ip address] 0.540345 Logged into UPS

Dir list! I'm using nut for many years on my home "server" without problems running on Debian 6.x nut version 2.4.3 Now I have decided to move to Debian 10. I have started from zero and install new system on a different disk. I have successfully installed new nut version 2.7.4 I've found one issue, that new version see always "low battery" state. Excerpt from syslog:

Hello, I have been following the details in this article to configure my UPS: http://rogerprice.org/NUT.html However the system won't shutdown although file permissions look ok: ls -alF /usr/sbin/ups* -rwxr--r-- 1 upsd daemon 64984 Oct 15 2014 /usr/sbin/upsd* -rwxr--r-- 1 upsd daemon 48584 Oct 15 2014 /usr/sbin/upsmon* -rwxr--r-- 1 upsd daemon 31536 Oct 15 2014 /usr/sbin/upssched*

Hi All, I have noticed these messages in my logs: ========================================= Sep 01 13:14:22 osmc upsd[1450]: listening on 127.0.0.1 port 3493 Sep 01 13:14:22 osmc upsd[1450]: listening on ::1 port 3493 Sep 01 13:14:22 osmc upsd[1450]: listening on 127.0.0.1 port 3493 Sep 01 13:14:22 osmc upsd[1450]: listening on ::1 port 3493 Sep 01 13:14:22 osmc upsd[1450]: Connected to UPS

I've built NUT 2.8.0 from source. When the nut-monitor runs: fopen upsmon.pid fails. I'm running as root, upsmon has root:root permissions as well as the other daemons and .conf files. I've tried configuring with and without --prefixpath --prefixaltpath. Is there something I am missing? Please see attached. Dan -------------- next part -------------- An HTML attachment was

I just did a fresh installation of Debian Jessie on one of my servers, but NUT won't configure and install. When I try to install, I get the following: Setting up nut-client (2.7.2-1+b2) ... Job for nut-monitor.service failed. See 'systemctl status nut-monitor.service' and 'journalctl -xn' for details. invoke-rc.d: initscript nut-client, action "start" failed.

> sudo launchctl list|fgrep -v com.app returns for me(10.12.5): PID Status Label - 78 org.networkupstools.upsmon system log: Jun 15 16:27:07 c01 com.apple.xpc.launchd[1] (org.networkupstools.upsmon): Service only ran for 0 seconds. Pushing respawn out by 10 seconds. Jun 15 16:27:17 c01 com.apple.xpc.launchd[1] (org.networkupstools.upsmon[4259]): Service could not initialize: 16F73:

Thanks for your help! In red below. Cheers simone On Thu, Jun 4, 2015 at 2:45 PM, Charles Lepple <clepple at gmail.com> wrote: > On Jun 3, 2015, at 11:45 AM, Simone Severini <severini.simone at gmail.com> > wrote: > > Hi everybody! > It has been a journey but I almost manage to make my UPS properly > communicate. > > This is the config: > > UPS

On Sun, 9 Jun 2019, Joe Gervasio wrote: > This question undermines my reading of the documentation.  I had thought that > these were separate things:  > >     SHUTDOWNCMD "/sbin/shutdown -u -h +1"  >     NOTIFYCMD /opt/local/sbin/upssched > > I had assumed that the SHUTDOWNCMD would be used by the Nut client (upsmon) to > shutdown the slave system,  and that

> > Did you see a line in the journal similar to this ? > Oct 06 22:49:54 pinta nut-delayed-ups-shutdown[1854]: > nut-delayed-ups-shudown.service calling > upsdrvctl to shut down UPS unit Never after I disabled the service. I pasted the whole journal section of the successful shutdown from last email. However I have been thinking about this line

Yes, that was the power off test. However the upssched-cmd script gave absolutely no signs of activity. Even it's logger lines don't show up in journalctl. No any permission error messages - nothing. Only the 2 messages from upsmon - on battery and then on line power. Here is the nut-report: http://www.filehosting.org/file/details/518300/NUT.report --- George Anchev On Tue, Oct 27,

Bill S wrote, On 4/15/2014 11:18 AM: > The problem is that when I run upsset.cgi I first get a prompt for > user name and password. I then enter the same username and password > as I established in upsd.users and it seems to accept it. upsset.cgi doesn't check that user/password is valid, it just tries it when doing a command. I just tested it, it is working for me on a remote and

FYI: PR https://github.com/networkupstools/nut/pull/1328 adds handling of `PRIMARY` alias to `MASTER` on protocol side, hopefully completing the puzzle for issue #840. Reviews and testing would be welcome :) On Sun, Mar 14, 2021, 00:34 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Thanks again for all the suggestions. > > For now I've prepared draft PRs, mostly to map out

FYI: PR https://github.com/networkupstools/nut/pull/1328 adds handling of `PRIMARY` alias to `MASTER` on protocol side, hopefully completing the puzzle for issue #840. Reviews and testing would be welcome :) On Sun, Mar 14, 2021, 00:34 Jim Klimov <jimklimov+nut at gmail.com> wrote: > Thanks again for all the suggestions. > > For now I've prepared draft PRs, mostly to map out

Good Evening, I recently purchased an EPYC quantum UPS. I installed NUT on the home assistant by connecting the UPS via USB and tried all the various drivers in the list, the only one that seems to work is: usbhid-ups with this log: s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service base-addon-banner: starting

Hi Leslie, 2014-09-29 17:14 GMT+02:00 Leslie Rhorer <lrhorer at mygrande.net>: > > I just did a fresh installation of Debian Jessie on one of my > servers, but NUT won't configure and install. When I try to install, I get > the following: > > Setting up nut-client (2.7.2-1+b2) ... > Job for nut-monitor.service failed. See 'systemctl status >

Thanks again for all the suggestions. For now I've prepared draft PRs, mostly to map out where the changes are needed - based on my earlier work with the originally proposed terminology. Now that we know where to change it, should not be too great a hassle to replace again by some other choice... subordinate was a bit too long to type :) To make the election of team choice more simple, I