Custom USV?

[jahlives]

Heute ist mein USV gekommen. Funzt soweit wunderbar und wir korrekt von der DS erkannt. Leider finde ich die Einstellungsmöglichkeiten im DSM etwas mager. Das System wechselt in den "abgesicherten Modus" wenn der Strom wegbricht.
Ich würde jedoch gerne zuvor den "Befehl" an den Webserver geben auch in den abgesicherten Modus zu wechseln.
Meine Fragen wären also:

• Welches Script wird ausgeführt um die DS in den abgesicherten Modus zu kriegen? Oder wird das mit einem Binary gemacht, wo man nichts so ohne weiteres anpassen kann?
• Kann man irgendwie einer anderen DS erlauben auf die DS mit dem USV zu verbinden und den USV Status auszulesen?

Mein USV ist ein APC USV BR500GI, Back-UPS RS Serie, 550VA/330W

 

[jahlives]

Die zweite Fragen kann ich jetzt selber beantworten:
Auf der DS wo das USV verbunden ist "Netzwerk USV-Server aktivieren" wählen und unter erlaubte IPs diejenige der anderen DS eintragen. Dann kann sie andere DS den USV Status beim Server abfragen und entsprechend reagieren.
Wenn ich jetzt noch wüsste welche Files involviert werden, dann könnte ich mir das selber was basteln.

Bleibt also noch die Frage ob jemand weiss welches Script/Datei die DS in den abgesicherten Modus schickt

 

[Matthieu]

Der Apache kennt einen abgesicherten Modus? Oder willst du ihn normal stoppen? Dann wären das die Start-Stop-Skripte unter /usr/syno/etc/rc.d

MfG Matthieu

 

[goetz]

Hallo,
aus der Hilfe des DSM

Wenn das System in den Sicheren Modus wechselt, werden zuerst alle Services angehalten und alle Datenvolumes getrennt, um einen Datenverlust zu verhindern. Wenn die USV herunterfährt, wird das System sicher ausgeschaltet. Wenn die Option Neustart nach Stromausfall aktiviert wird, wird das System automatisch neu gestartet, sobald die Stromversorgung wiederhergestellt ist. Sie können die Funktion Neustart nach Stromausfall unter "System > Netzstrom" aktivieren.

mit anderen Worten, der Indianer ist gestoppt.

Gruß Götz

 

[jahlives]

Ich würde jedoch gerne zuvor den "Befehl" an den Webserver geben auch in den abgesicherten Modus zu wechseln.

Mit Webserver meinte ich nicht den Apache sondern die 2. DS die als Webserver fungiert. Sorry mein Fehler
Aber es geht ja damit wenn ich die DS am USV als Netzwerk-USV-Server einstelle. Dann kann die 2. DS (Webserver) den Status des USV auch abfragen und entsprechend reagieren.
Ich habe es jetzt so gemacht:
Die erste DS mit USB Verbindung zum USV geht 3 Minuten nach Beginn der Batteriestützung in den abgesicherten Modus. Die zweite DS geht nach einer Minute in den Safe Mode. Nachdem die erste DS auch im Safe Mode ist schaltet sie das USV ab. Beide DS springen wieder an sobald das USV wieder Netzstrom hat.
Funzt soweit perfekt...
Anfangs hatte ich mit einiger opt Software Probleme die bei script stop, den Prozess killten und gleich wieder anwarfen. Das hat natürlich dann den Safe Mode erstmal verhindert. Die Scripte habe ich angepasst und die opt Software wird sauber beendet.
Komischerweise finden im SafeMode noch Festplattenzugriffe statt (zumindest auf der DS die direkt mit dem USV verbunden ist).
Mangels Konsolenzugriff in diesem Zustand kann ich jedoch nicht prüfen ob und was noch gemountet sein könnte.
@goetz
könnte ich mit deinem Kabel im SafeMode noch auf die DS kommen und nachschauen was noch eingehängt ist?
Der upsmon Daemon sagt übrigens bei Starten auf der Konsole, dass das File /etc/killpower (oder so war in der Art) angelegt würde, wenn die DS in den SafeMode geht. Könnte es sein, dass dies das "ominöse" Flag setzen könnte, das eine DS dazu bringt nach dem Stromausfall wieder zu starten??

Gruss

tobi

 

[jahlives]

hhm...
Also es scheinen definitiv gemountete "Dinge" auf der DS mit USB zum USV vorhanden zu sein. Der Boot, der eingeleitet wurde als das USV wieder Strom hatte dauerte fast 15 Minuten. Das deutet für mich auf einen Filesystemcheck hin.
Die andere DS bootete normal in gut 60 Sekunden. Beide DS haben ipkg am Start und von dem her denke ich nicht, dass es ein Problem mit dem /opt-mount besteht.
Gerade mal die Logs angeschaut es sind etliche Meldungen zum Filesystem drin

Jan  7 19:22:12 mail EXT4-fs warning (device ram0): ext4_fill_super: extents feature not enabled on this filesystem, use tune2fs.
Jan  7 19:22:12 mail EXT4-fs warning (device ram0): ext4_fill_super: extents feature not enabled on this filesystem, use tune2fs.
Jan  7 19:22:12 mail EXT3 FS on md0, internal journal
Jan  7 19:22:12 mail EXT3-fs: mounted filesystem with ordered data mode.
Jan  7 19:22:12 mail EXT3 FS on md0, internal journal
Jan  7 19:22:12 mail EXT3-fs: mounted filesystem with ordered data mode.
Jan  7 19:22:12 mail EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
Jan  7 19:22:12 mail EXT3 FS on md2, internal journal
Jan  7 19:22:12 mail EXT3-fs: recovery complete.
Jan  7 19:22:12 mail EXT3-fs: mounted filesystem with writeback data mode.
Jan  7 19:22:12 mail EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
Jan  7 19:22:12 mail EXT3 FS on md2, internal journal
Jan  7 19:22:16 mail EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
Jan  7 19:22:16 mail EXT3 FS on sdk1, internal journal
Jan  7 19:22:16 mail EXT3-fs: mounted filesystem with ordered data mode.
Jan  7 19:32:41 mail EXT4-fs warning (device ram0): ext4_fill_super: extents feature not enabled on this filesystem, use tune2fs.
Jan  7 19:32:41 mail EXT4-fs warning (device ram0): ext4_fill_super: extents feature not enabled on this filesystem, use tune2fs.
Jan  7 19:32:41 mail EXT3 FS on md0, internal journal
Jan  7 19:32:41 mail EXT3-fs: mounted filesystem with ordered data mode.
Jan  7 19:32:41 mail EXT3 FS on md0, internal journal
Jan  7 19:32:41 mail EXT3-fs: mounted filesystem with ordered data mode.
Jan  7 19:32:41 mail EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
Jan  7 19:32:41 mail EXT3 FS on md2, internal journal
Jan  7 19:32:41 mail EXT3-fs: recovery complete.
Jan  7 19:32:41 mail EXT3-fs: mounted filesystem with writeback data mode.
Jan  7 19:32:41 mail EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
Jan  7 19:32:41 mail EXT3 FS on md2, internal journal
Jan  7 19:32:45 mail EXT3-fs warning: mounting fs with errors, running e2fsck is recommended
Jan  7 19:32:45 mail EXT3 FS on sdk1, internal journal
Jan  7 19:32:45 mail EXT3-fs: recovery complete.
Jan  7 19:32:45 mail EXT3-fs: mounted filesystem with ordered data mode.

Der Boot wurde um ca 19:13 eingeleitet als das USV wieder Strom hatte

 

[jahlives]

Ich habe mir mal upsmon angeschaut. Mal ein bisschen mit den Parametern rumprobiert. Mit upsmon -K wird das File /etc/killpower geprüft. Ich vermute, dass upsmon auch den SafeMode einleiten kann. Ich habe das File testweise mal angelegt. Das scheint aber nicht zu reichen

upsmon -K
Network UPS Tools upsmon 2.2.2
UPS: ups@localhost (master) (power value 1)
Using power down flag file /etc/killpower

POWERDOWNFLAG (/etc/killpower) does not contain the upsmon magic string

Weiss jemand wie man diesen magic string rausbekommen kann. Ein simples 1 oder 0 reicht leider nicht als Inhalt. Gibt es in der Firmware ein File, das diese magic strings beinhaltet?
Ich habe das Gefühl, dass dies der Weg sein könnte jede DS mittels Zeitschaltuhr und Cronjob zeitgesteuert zu stoppen und zu starten.
Man müsste nur diesen SafeMode Zustand einleiten können. Ein zwei Minuten später könnte die Zeitschaltuhr den Strom kappen. Sobald dann der Strom wieder geschaltet wird sollte die DS wieder hochfahren

 

[goetz]

Hallo,
häng mal den Adapter ran, wenn die Loginshell noch läuft kommst Du auch rauf. Eventuell sieht Du auf der seriellen Konsole auch noch mehr Ausgaben was da so ausgeführt wird. Auf jeden Fall wirst Du ein umount failed, 16 finden, denn Du bekommst ja beim starten ein recovery complete, ergo quotacheck.
Spannende Sache mit dem Savemode, wenn der sich per Hand einschalten ließe.

Gruß Götz

 

[goetz]

Hallo,
schau mal /usr/syno/bin/synoups

...
UPSSafeMode() {
    if [ -f $SZF_SAFEMODE ]; then
        return
    fi
    St=`UPSStatusGet`
    if [ "$St" = "OL" ]; then
        echo "WARNING: UPS is On-Line"
        return
    fi
    echo "$1" > $SZF_SAFEMODE

    synologset1 sys warn 0x11300011
    SYSLOG "UPS going to stop all services and umount all volumes."

    killall -9 mplayer
    loop=0
    while [ $loop -lt 5 ]; do
        mplayer_pids=`pidof mplayer`
        if [ $? -ne 0 ]; then
            break
        fi
        for pid in $mplayer_pids ; do
            kill -9 $pid
        done
        loop=`expr $loop + 1`
    done

    for s in `ls /usr/local/etc/rc.d/*`; do
        $s stop > /dev/null 2>&1
    done
    for s in `ls /usr/syno/etc/rc.d/S*.sh | sort -r`; do
        case "`basename $s`" in
        S02hotplugd.sh)
            ;;
        *)    
            $s stop > /dev/null 2>&1
            ;;
        esac
    done

    for v in `grep volume /proc/mounts | awk '{print $2}'`; do
        umount -f $v
    done

    echo "7" > /dev/ttyS1
    sync; sync; sync;

    echo "Stop all services and umount all volumes" >> $SZF_SAFEMODE
    UPSShutdown
} 
...

irgendwie trivial

Gruß Götz

 

[goetz]

Hallo,
als kleine Anregung

#!/bin/sh
        SYSLOG "admin going to stop all services and umount all volumes."

        killall -9 mplayer
        loop=0
        while [ $loop -lt 5 ]; do
                mplayer_pids=`pidof mplayer`
                if [ $? -ne 0 ]; then
                        break
                fi
                for pid in $mplayer_pids ; do
                        kill -9 $pid
                done
                loop=`expr $loop + 1`
        done


        for s in `ls /opt/etc/init.d/S* | sort -r`; do
                case "`basename $s`" in
                S02hotplugd.sh)
                        ;;
                *)
                        $s stop > /dev/null 2>&1
                        ;;
                esac
        done
        for s in `ls /usr/local/etc/rc.d/*`; do
                $s stop > /dev/null 2>&1
        done
        for s in `ls /usr/syno/etc/rc.d/S*.sh | sort -r`; do
                case "`basename $s`" in
                S02hotplugd.sh)
                        ;;
                *)
                        $s stop > /dev/null 2>&1
                        ;;
                esac
        done

        for v in `grep volume /proc/mounts | awk '{print $2}'`; do
                umount -f $v
        done

        echo "7" > /dev/ttyS1
        sync; sync; sync;

        echo "Stop all services and umount all volumes"

Wer moch extra cron-jobs laufen hat muß sich um das killen der Prozesse kümmern falls sie gerade laufen.

Gruß Götz

 

[jahlives]

Habe mal ein bisschen an der Datei rumgespielt. Mit synoups lowbatt werden die meisten Dienste beendet. Das System bleibt aber über telnet erreichbar und die Parts sind alle noch gemountet. Erst ein synoups fsd macht dann die Schotten komplett dicht (Status LED erlischt).

 

[goetz]

Hallo,
das Problem beim Start aus ssh/telnet bei lowbatt ist, Du schießt den sshd/telnet ab und somit die shell und das script. Sollte aber per cron funktionieren.
Mein Beispiel von der seriellen gestartet killt so gut wie alles, LED geht aus aber gleich wieder blinkend an. Als cron-Job und nicht auf der seriellen eingeloggt läuft es aber durch und LED bleibt aus. synoups setzt aber eine physische USV vorraus, ohne geht es leider nicht (ich habe keine).

DS-106 login: nfsd: last server has exited
nfsd: unexporting all filesystems
rpciod: active tasks at shutdown?!
fs_close_all_files: force to close file c2811120
fs_close_all_files: force to close file c06af5e0
fs_close_all_files: force to close file c2811220
fs_close_all_files: force to close file c06afd60
fs_close_all_files: force to close file c2e6a220
fs_close_all_files: force to close file c1d88be0
fs_close_all_files: force to close file c07e6da0
fs_close_all_files: force to close file c1f728e0
fs_close_all_files: force to close file c1d886e0
fs_close_all_files: force to close file c1d883e0
fs_close_all_files: force to close file c1d885e0
fs_close_all_files: force to close file c1d88460
fs_close_all_files: force to close file c3ad0bc0
fs_close_all_files: force to close file c3ad0640
fs_close_all_files: force to close file c3fa5920
fs_close_all_files: force to close file c3ad06c0
sys_umount: force unmount success

Wenn ich mich jetzt seriell einlogge laufen noch folgende Prozesse

DS-106> ps ax
  PID  Uid     VmSize Stat Command
    1 root        256 S   init
    2 root            SW  [keventd]
    3 root            SWN [ksoftirqd_CPU0]
    4 root            SW< [kswapd]
    5 root            SW  [bdflush]
    6 root            SW  [kupdated]
    7 root            SW  [kinoded]
    8 root            SW  [mtdblockd]
  121 root            SW  [kjournald]
  205 root            SW  [khubd]
  334 root        488 S   /sbin/dhcpcd -n eth0 -t 30
  356 root        312 S   /sbin/syslogd -S
  358 root        304 S   /sbin/klogd
  388 root       1148 S < /usr/syno/bin/findhostd
  497 root       1064 S   /usr/syno/sbin/hotplugd
  591 root       1660 S   /usr/syno/bin/scemd
  813 root        368 S   -ash
 9723 root        924 S   /opt/sbin/xinetd
10225 root        764 R   ps ax

also nichs wichtiges (/opt ist ein Symlink). Auf der seriellen ein reboot und sie fährt sauber wieder hoch.
Nächster Test, per cron in savemode, Strom klauen. Warten .......
Jup, das klappt, kein recovery complete, kein quotacheck, fährt sauber hoch.

Hi Tobi, coole Sache was Du da gefunden hast, geplantes einschalten bei den alten Möhren mit ein ein paar Tricks gefahrlos möglich.
Danke!

Gruß Götz

PS: mag sein,daß die blinkende Status-LED von einem laufenden snmpwalk stammt.

 

[itari]

Hi Tobi, coole Sache was Du da gefunden hast, geplantes einschalten bei den alten Möhren mit ein ein paar Tricks gefahrlos möglich.

Hi Götz,

könntest das noch ein wenig ausformulieren? Das 'geplante' Einschalten?

Danke

Itari

 

[goetz]

Hallo,
wird das script per cron zB. um 01:00 gestartet geht die DS in den Savemode und kann gefahrlos vom Strom genommen werden, also Schaltuhr auf 01:05 stellen. Wenn die Schaltuhr zB. um 06:00 einschaltet fährt die DS automatisch wieder hoch (im DSM Energieverwaltung "Nach Stromausfall automatisch starten" muß angehakt sein).
Jeder eigene Sonderdrösel (mount -o bind, Sachen im cron die noch laufen könnten usw.)muß gesondert in dem script behandelt werden. IPKG sollte von mount auf Symlink umgestellt werden oder explizit im script ausgehangen werden (klappt aber nicht immer).

Gruß Götz

 

[itari]

Jetzt blick ich: du meinst Einschalten per Schaltuhr Ich dachte schon, du hast das Einstellen eines internen Weckers bei den älteren DSen gefunden.

Alles klar.

Itari

 

[goetz]

Hallo,
nein nein, ich habe gar nichts gefunden, der Tobi wars. Den alten Modellen fehlt einfach ein Stück Hardware, vermutlich das worauf ein Aufkleber mit Versionsnummer ist.

Gruß Götz

 

[HarryPotter]

Auf der DS wo das USV verbunden ist "Netzwerk USV-Server aktivieren" wählen und unter erlaubte IPs diejenige der anderen DS eintragen. Dann kann sie andere DS den USV Status beim Server abfragen und entsprechend reagieren.

Das funktioniert ausgezeichnet.

Mich würde jetzt aber interessieren ob es irgenwo eine kostenlose Software gibt, die dasselbe für den PC erledigt (die also diese Daten von der DS liest und entsprechend den PC rechzeitig runterfährt oder in den Standby Modus setzt oder so).

 

[goetz]

Hallo,
schau Dir mal WinNUT an, bin ich gerade im englischen Forum drüber gestoplert (NUT Network UPS Tools).

Gruß Götz

 

[HarryPotter]

Ja das habe ich auch gesehen. Dort steht

This allows you to monitor a ups with a serial (or usb) connection to another machine

Es müsste aber übers Netzwerk gehen...

 

[goetz]

Hallo,
die Formulierung ist da nicht so richtig eindeutig. Klarer wirds im Configfile.

# MONITOR <system> <powervalue> <username> <password> ("master"|"slave")
#
# List systems you want to monitor.  Not all of these may supply power
# to the system running upsmon, but if you want to watch it, it has to
# be in this section.
# 
# You must have at least one of these declared.
#
# <system> is a UPS identifier in the form <upsname>@<hostname>[:<port>]
# like localhost, su700@mybox, etc.
# 
# Examples:
# 
#  - "su700@mybox" means a UPS called "su700" on a system called "mybox"
#
#  - "fenton@bigbox:5678" is a UPS called "fenton" on a system called
#    "bigbox" which runs upsd on port "5678".
#
# The UPS names like "su700" and "fenton" are set in your ups.conf
# in [brackets] which identify a section for a particular driver.
#
# If the ups.conf on host "doghouse" has a section called "snoopy", the
# identifier for it would be "snoopy@doghouse".

Ein Beispiel gibts hier (ganz unten).

Gruß Götz