Hi Todd,
On my Synology boxes which are currently running DSM 6.2.3 Update 2,
Control Panel / Hardware & Power / UPS:
Enable UPS support
Network UPS type: Synology UPS server
Time before DiskStation enters Safe mode: 15 min
Network UPS server IP: x.x.x.x
I should probably lower the Safe
Hey everyone,
I did a manual test by physically disconnecting power to the ups and
everything worked. I guess the Synology is dumb about doing it via the “upsmon
-c fsd” command. All slaves shutdown, the Synology went into safe mode, then
the master shut down, then two minutes later the ups
On Fri, 14 Aug 2020, Todd Benivegna wrote:
https://forum.synology.com/enu/viewtopic.php?f=19=73960=ups+slave
I have the latest version of the Windows port of NUT (A UPS management
package) installed on my Windows 7 machine. The UPS I am using is a
very old APC BK650M which is
I found something interesting that I think may apply here. Check this
out...
https://forum.synology.com/enu/viewtopic.php?f=19=73960=ups+slave
*I have the latest version of the Windows port of NUT (A UPS management
package) installed on my Windows 7 machine. The UPS I am using is a very
old
Sorry, I guess it is */usr/syno/bin/synoups*
On Fri, Aug 14, 2020 at 2:27 PM Todd Benivegna wrote:
> I found something interesting that I think may apply here. Check this
> out...
>
>
>
> https://forum.synology.com/enu/viewtopic.php?f=19=73960=ups+slave
>
> *I have the latest version of the
Thanks Larry, no problem. I appreciate the input. Whenever you get a chance I’d
really like to compare notes with someone who has NUT and a Synology to see why
the heck mine doesn’t work! ;). I’m also using my Pi as the master like you.
Thanks.
Todd
--
Todd Benivegna // t...@benivegna.com
On
On Fri, Aug 14, 2020 at 10:31 AM Todd Benivegna wrote:
> I have not edited a single file, including anything to do with NUT, on the
> Synology via ssh ever. How is yours configured in the UI? Do you have
> it set to go into safe mode after a certain number minutes?
>
Hi Todd,
I
Larry,
I have not edited a single file, including anything to do with NUT, on the
Synology via ssh ever. How is yours configured in the UI? Do you have it
set to go into safe mode after a certain number minutes?
Earlier, I was just copying and pasting the contents of some files to Roger
On Fri, Aug 14, 2020 at 9:21 AM Aleksandr Karenin
wrote:
> >I wonder how difficult it would be to rip off their modifications and
> revert to a.standard, functional nut.
>
> I think it should be preatty simple. just rename Synology files and
> replacewith what you think is the best there... it's
>I wonder how difficult it would be to rip off their modifications and revert
>to a.standard, functional nut.
I think it should be preatty simple. just rename Synology files and replacewith
what you think is the best there... it's just a banch of scripts nothing more...
On Fri, 14 Aug 2020, Larry Fahnoe wrote:
I wonder if as a result of the tinkering and testing something has gotten
mucked up in your Synology's config...perhaps in the config files you were
editing? I wonder this because with a stock Synology UPS configuration as a NUT
client to my
On Thu, Aug 13, 2020 at 7:46 PM Todd Benivegna wrote:
> So I finally got a test in after I changed my RPi to the master and
> everything else (including my Synology) to slaves. Before I did that
> though, I timed the shutdown of my Synology since it is the slowest slave
> to shutdown. It took
Fortunately, several messages earlier there was an explanation how Synology has
implemented UPS management.
So SHUTDOWN CMD "" is a normal behaviour. It is managed by scripts outside of
NUT.
Alex
___
Nut-upsuser mailing list
On Thu, 13 Aug 2020, Todd Benivegna wrote:
I’d do that, but I have no idea how to write scripts or setup the trigger….
Aside from the Synology problem, it would help you a lot as a system
administrator if you learned to write simple Bash scripts.
On Thu, 13 Aug 2020, Todd Benivegna wrote:
So I finally got a test in after I changed my RPi to the master and everything
else (including my Synology) to slaves. Before I did that though, I timed the
shutdown of my Synology since it is the slowest slave to shutdown. It took 40
seconds to
Not much in the way of configuration…. I’m pretty sure I’ve got it correct.
--
Todd Benivegna // t...@benivegna.com
On Aug 13, 2020, 8:54 PM -0400, Manuel Wolfshant ,
wrote:
> On August 14, 2020 3:46:05 AM GMT+03:00, Todd Benivegna
> wrote:
> > So I finally got a test in after I changed my
On August 14, 2020 4:34:17 AM GMT+03:00, Manuel Wolfshant
wrote:
>On August 14, 2020 4:01:17 AM GMT+03:00, Todd Benivegna
> wrote:
>>Not much in the way of configuration…. I’m pretty sure I’ve got it
>>correct.
>>
>
>We have a saying here "do not force it, use a bigger hammer".
>Just setup a
> We have a saying here "do not force it, use a bigger hammer".
> Just setup a timer on proton triggered by LB (or whenever you seem fit , like
> "5 more minutes of power left" ). When activated, have a script connect via
> ssh to the NAS and kindly ask it to shutdown (i.e "ssh admin@Synoligy
>
On August 14, 2020 4:01:17 AM GMT+03:00, Todd Benivegna
wrote:
>Not much in the way of configuration…. I’m pretty sure I’ve got it
>correct.
>
We have a saying here "do not force it, use a bigger hammer".
Just setup a timer on proton triggered by LB (or whenever you seem fit , like
"5 more
On August 14, 2020 3:46:05 AM GMT+03:00, Todd Benivegna
wrote:
>So I finally got a test in after I changed my RPi to the master and
>everything else (including my Synology) to slaves. Before I did that
>though, I timed the shutdown of my Synology since it is the slowest
>slave to shutdown. It
So I finally got a test in after I changed my RPi to the master and everything
else (including my Synology) to slaves. Before I did that though, I timed the
shutdown of my Synology since it is the slowest slave to shutdown. It took 40
seconds to shutdown, so I changed HOSTSYNC in upsmon.conf
This fixed everything! Everything appears to be working ok now and all clients
are connected. Thank you!
Going to test everything out now.
--
Todd Benivegna // t...@benivegna.com
On Aug 12, 2020, 6:16 PM -0400, Charles Lepple , wrote:
> On Aug 12, 2020, at 5:32 PM, Todd Benivegna wrote:
> >
>
On Aug 12, 2020, at 5:32 PM, Todd Benivegna wrote:
>
>> Those LISTEN lines were appropriate pre-systemd when NUT's startup script
>> was launched after networking was fully enabled. I would recommend "LISTEN
>> 0.0.0.0 3493" instead, and use firewall rules if you are trying to exclude
>> an
> If you have problems with having the NAS as master, make it a slave, and run
> the
> NUT configuration of your choice in your PC/workstation.
I have done just this. I changed the Synology to a slave and made my Raspberry
Pi master and the rest of my servers are slaves as well. Manuel
555 gives no write access to the dir, and the files are covered by their
own perms, so I fail to see any relevance to your comment - sorry . . .
640 is decent for files, not so much for directories - as noted, the
fields mean different things on dirs . . .
From the man pages:
The
On Aug 12, 2020, at 12:11 AM, Todd Benivegna wrote:
>
> Here is my upsd.conf:
>
> LISTEN 127.0.0.1 3493
> LISTEN 192.168.1.31 3493
>
Those LISTEN lines were appropriate pre-systemd when NUT's startup script was
launched after networking was fully enabled. I would recommend "LISTEN 0.0.0.0
The only reason NUT may whant to modify it's config is NUT-CGI and may be
Synology GUI.
Even then default install on my Synology makes no trubble.
___
Nut-upsuser mailing list
Nut-upsuser@alioth-lists.debian.net
On 8/12/20 8:10 AM, Tim Dawson wrote:
For directory permissions, the "x" priv determines if you can access
the directory, so going from 555 (r-x,r-x,r-x) to 640 (rw-,r--,---)
pretty much locks out access to the dir. Myself, I'd go back to 555.
640 essentially locks the group "nut" out . . .
On 8/12/20 7:11 AM, Todd Benivegna wrote:
Ok, so just a follow-up to my last email; still following that guide,
which is great…. Just stuck on getting the nut-server service starting
automatically. Got everything else working. I’ve been able to get
the nut-client starting up automatically at
On Wed, 12 Aug 2020, Manuel Wolfshant wrote:
So nut on Synology believes that it is a good idea to trigger a FSD 30 secs
AFTER switching back to line power when in fact it should CANCEL any shutdown
in progress. Unless you have the willingness to search & fix whatever
stupidities they do in
Ok, so just a follow-up to my last email; still following that guide, which is
great…. Just stuck on getting the nut-server service starting automatically.
Got everything else working. I’ve been able to get the nut-client starting up
automatically at boot up (I had a missing “1” in
Thanks Manuel. I’m following that guide but am now stuck when checking to make
sure the nut-sever and nut-client are up and working. I got this:
proton@proton:~$ service nut-server status
nut-server.service - Network UPS Tools - power devices information server
Loaded: loaded
On 8/12/20 3:55 AM, Todd Benivegna wrote:
Manuel,
You are absolutely right. I think this is all the Synology just being
very dumb. I guess those are my only two options at this point.
I have no idea on how to set up the NUT server though on one of my
NUCs or my Pi. Do you know any good
Yeah I saw that. Makes no sense. I can Wireshark it, however even if I find
the cause, I’d still have to go to Synology for resolution, which I doubt will
ever get fixed. Even if they do, I doubt it’d be any time soon. Maybe that’s
me being pessimistic, I don’t know, but I just don’t if I
On 8/12/20 3:42 AM, Manuel Wolfshant wrote:
On 8/12/20 3:20 AM, Todd Benivegna wrote:
Hi everyone,
Well, we lost power here again. I was not at home, but I guess a
dump truck smashed into some power poles and took out half the city;
actually tripped most of the breakers in the panel.
Manuel,
You are absolutely right. I think this is all the Synology just being very
dumb. I guess those are my only two options at this point.
I have no idea on how to set up the NUT server though on one of my NUCs or my
Pi. Do you know any good guides out there? I’m guessing it’s easy
On 8/12/20 3:20 AM, Todd Benivegna wrote:
Hi everyone,
Well, we lost power here again. I was not at home, but I guess a dump
truck smashed into some power poles and took out half the city;
actually tripped most of the breakers in the panel. Anyways, the
power was out for just a few seconds
Hi everyone,
Well, we lost power here again. I was not at home, but I guess a dump truck
smashed into some power poles and took out half the city; actually tripped most
of the breakers in the panel. Anyways, the power was out for just a few
seconds and of course my servers shutdown on me
On Tue, Aug 11, 2020 at 12:46 AM Roger Price wrote:
> On Mon, 10 Aug 2020, Todd Benivegna wrote:
>
> > synoups: https://hastebin.com/xexafofiha.bash
>
> Wow! What a mess. It looks as if Synology wanted to write their own
> "NUT", but
> decided it would be easier to put their ideas in a script
On Mon, 10 Aug 2020, Todd Benivegna wrote:
synoups: https://hastebin.com/xexafofiha.bash
Wow! What a mess. It looks as if Synology wanted to write their own "NUT", but
decided it would be easier to put their ideas in a script when they saw they
could use upssched.conf to call it. NUT
Here ya go, this should work.
synoups:
https://hastebin.com/xexafofiha.bash
Todd
--
Todd Benivegna // t...@benivegna.com
On Aug 10, 2020, 9:04 AM -0400, Todd Benivegna , wrote:
> Wow. That’s weird. Blank for me too! I will send again when I get home. Sorry
> about that!
>
> --
> Todd Benivegna
Wow. That’s weird. Blank for me too! I will send again when I get home. Sorry
about that!
--
Todd Benivegna // t...@benivegna.com
On Aug 10, 2020, 9:01 AM -0400, Roger Price , wrote:
> On Mon, 10 Aug 2020, Todd Benivegna wrote:
>
> > Here is the /usr/syno/bin/synoups file
> >
Hi Roger,
Here is the /usr/syno/bin/synoups file
https://hastebin.com/sibopejuyu.bash
Thanks,
Todd
--
Todd Benivegna // t...@benivegna.com
On Aug 9, 2020, 4:49 PM -0400, Roger Price , wrote:
> On Sun, 9 Aug 2020, Todd Benivegna wrote:
>
> > upssched.conf (on Synology):
> > CMDSCRIPT
On Sun, 9 Aug 2020, Todd Benivegna wrote:
upssched.conf (on Synology):
CMDSCRIPT /usr/syno/bin/synoups
upssched-cmd (on Synology):
I don’t see this file.
The CMDSCRIPT declaration says that in a Synology box the file that NUT calls
upssched-cmd is called /usr/syno/bin/synoups. Could we
On Aug 9, 2020, at 3:18 PM, Todd Benivegna wrote:
>
> Now they will spin-up on their own, but it takes 5-10 seconds. My thought
> was if they can’t communicate initially, they assume the server is dead and
> shut down. Would that make sense at all?
Sorry to jump in the middle here, but
> Since it's NUT in the NAS which is deciding to order the shutdown, it would be
> useful to see upsmon.conf, upssched.conf and upssched-cmd (or whatever
> Synology
> use if anything) from the NAS to see what criteria they use.
upsmon.conf (on Synology):
RUN_AS_USER root
MONITOR ups@localhost 1
On Sat, 8 Aug 2020, Todd Benivegna wrote:
I just ran a manual test, killing power and see what happens. I set the
Synology “Time before DiskStation goes into Safe mode”
What is "Safe mode"? Is it complete power down?, or some sort of hibernation?
If it's not a complete power down, how is
On Sat, 8 Aug 2020, Todd Benivegna wrote:
Updated upsmon.conf: https://hastebin.com/jisinaquso.pl
You should remove line 1 : RUN_AS_USER nut
Lines 12-21: it would be possible to display more information, such as the UPS
status, but this requires pointing NOTIFYCMD to upssched and then
On Fri, 7 Aug 2020, Todd Benivegna wrote:
I don’t think I am able to run that script. If you can, I wouldn’t know how.
You have to activate SSH on the NAS, log in to the NAS as root (admin) and
create a temporary directory. Based on what I read on a french language site,
the commands are:
On Fri, 7 Aug 2020, Todd Benivegna wrote:
Hello Todd, sorry for the delay replying, I was away for a while. It's ok to
post configuration files in this list if blank lines and comments are removed.
On the Synology (I didn’t edit any of these files):
ups.conf:
Roger,
I just ran a manual test, killing power and see what happens. I set the
Synology “Time before DiskStation goes into Safe mode” to 5 minutes so I didn’t
have to wait like an hour until it powered down. Here is the log:
https://hastebin.com/ovuwilufeb.sql
Everything appeared to be
Roger,
Ok, so how does this look...
Updated upsmon.conf: https://hastebin.com/jisinaquso.pl
> I'm guessing that the UPS supplies only the NAS, not the 3 Ubuntu machines. Do
> they have their own UPS's?
No, the Synology and the three servers are all on the one UPS (also my switch
and spare
On Fri, 7 Aug 2020, Todd Benivegna wrote:
APC Back-UPS NS 650M1 UPS ---USB---> Synology NAS (DS416 - Master?)
---Ethernet---> Netgear Managed Switch w/ uplink to router <---Ethernet---
Servers (Ubuntu 20.04 - Plex, Pulsar, Proton - All three set as slaves)
I'm guessing that the UPS supplies
upsmon.conf on server: https://pastebin.com/z4CrUTxb
nut.conf on server: https://pastebin.com/540ShZH7
Permissions for /etc/nut: https://hastebin.com/qecolodapi.diff
On the Synology (I didn’t edit any of these files):
ups.conf: https://hastebin.com/dedereqizi.shell
upsd.conf:
Hi Roger,
I am not home, but when I do get home I will check out everything you've
mentioned. I do have some time where I can give you a breakdown of my
topology though. I have a feeling all of this is probably due to a
configuration error somewhere on my part. Here's what I have done so far.
On Fri, 7 Aug 2020, Roger Price wrote:
Is it possible to run script http://rogerprice.org/NUT/nut-report on the NAS?
No need, it's sufficient to tell us the contents of files upsd.conf, upsd.users
and ups.conf probably in DS416 directory /usr/syno/etc/ups . Remove your
passwords, and please
On Thu, 6 Aug 2020, Todd Benivegna wrote:
... I grep’d the syslog and here’s the results:
Could you also grep for upsd and upsmon in the NAS log? Is this possible?
proton@proton:~$ sudo grep upsmon /var/log/syslog
Aug 6 19:19:09 proton upsmon[1552]: UPS ups@192.168.1.70 on
Ok guys,
So we just had a storm roll through and of course we lost power for just a
split second. This time I was actually home for it. Sure enough, the servers
shutdown and wouldn’t boot all the way up until I restarted my Synology. I
grep’d the syslog and here’s the results:
>
> grep nut /etc/passwd
nut:x:129:134::/var/lib/nut:/usr/sbin/nologin
> In your manual test do you restore utility power after 3-5 seconds?
Yes, I have tried that. I have also tried less than one second. I’ve tried
for 1-2 minutes, for 3-5 minutes, I’ve tried just about every length of time
On Tue, 4 Aug 2020, Todd Benivegna wrote:
Sorry. I've lost the thread here, what is the "it" you refer to?
I’m not an linux expert so you’ll have to bear with me, but I guess the it I
was referring to whatever NUT is using since what we’re editing is a config
file, not a script; it
> Sorry. I've lost the thread here, what is the "it" you refer to?
I’m not an linux expert so you’ll have to bear with me, but I guess the it I
was referring to whatever NUT is using since what we’re editing is a config
file, not a script; it doesn’t have a shebang at the top.
> If you run the
On Tue, 4 Aug 2020, Todd Benivegna wrote:
Right, but I don't know what NUT script is actually calling it. I don't know
how else I would check.
Sorry. I've lost the thread here, what is the "it" you refer to?
If you run the command
grep nut /etc/password
you will probably receive a reply
On 8/4/20 5:43 PM, Todd Benivegna wrote:
Right, but I don't know what NUT script is actually calling it. I
don't know how else I would check.
you could
- use SHUTDOWNCMD ="|echo $SHELL > /tmp/WhatShellIsInUse" and check
the content of that file after a shutdown is triggered
|
|-
Right, but I don't know what NUT script is actually calling it. I don't
know how else I would check.
On Tue, Aug 4, 2020 at 10:21 AM Manuel Wolfshant
wrote:
> On 8/4/20 4:16 PM, Todd Benivegna wrote:
> > Ok, so now that I think of it, that might not actually work when it is
> > not run by me.
On 8/4/20 4:16 PM, Todd Benivegna wrote:
Ok, so now that I think of it, that might not actually work when it is
not run by me. I guess that it all confirms that it works in Bash,
but I think when it runs on its own it would use Dash...
it uses whatever shell you ask for in the first line of
Ok, so now that I think of it, that might not actually work when it is not
run by me. I guess that it all confirms that it works in Bash, but I think
when it runs on its own it would use Dash...
The default login shell remains bash. Opening a terminal from the menu or
> shortcut [crtl-alt-t]
Ok, gotcha, I did that. I believe Ubuntu uses Bash for user sessions and Dash
fornscripts, so followed your instructions for Dash. I put the getUPStatus bits
in .bashrc and tested in Terminal and got:
UPS status is [OL]:100
So I went ahead and put your SHUTDOWNCMD in upsmon.conf. I think it
On Mon, 3 Aug 2020, Todd Benivegna wrote:
Thank you! Sorry for another bonehead question…. Do I replace with
the IP address of the NUT Server/Synology? I’m assuming I would use this
version for use in Dash with Ubuntu, correct?
Yes, you replace with the address of your UPS, for example
Thank you! Sorry for another bonehead question…. Do I replace with the
IP address of the NUT Server/Synology? I’m assuming I would use this version
for use in Dash with Ubuntu, correct?
--
Todd Benivegna // t...@benivegna.com
On Aug 3, 2020, 5:33 AM -0400, Roger Price , wrote:
> On Sun, 2
On Sun, 2 Aug 2020, Todd Benivegna wrote:
How would you write the SHUTDOWNCMD line with multiple commands? I’ve been
looking at the manual and see that you have to escape the internal “ but am
still a little confused on how to do this exactly.
This assumes that you use the Bash shell in
70 matches
Mail list logo
