Custom USV?

[HarryPotter]

So geil, es funktioniert

Habe in der Konfiguration angegeben, er solle nach 5 Sekunden runterfahren, dann den Stecker gezogen.

Kommt gleich die Meldung ups sei "on battery" und 5 Sec. später hat sich der Compi ganz brav ausgeschaltet.


Gut, man sieht eigentlich nichts, weiss nicht richtig ob alles ok ist, aber es klappt

 

[jahlives]

@goetz
Also bei mir fliege ich zwar aus der aktuellen telnet Session bei lowbatt, aber ich kann mich immer noch einloggen.
"Witzig" an der ganzen Sache finde ich ja, dass es mit einem USV zum quotacheck kommt und ohne ganz sauber funzt. Das muss an der USB Verbindung des USV zur DS hängen. Wenn ich die USV USB Verbindung zur anderen DS mache - wo vorher ohne quotacheck gestartet werden konnte - dann habe ich den quotacheck auf dieser Maschine. Es scheint mir, dass der USV Master (jene DS mit USB Verbindung zum USV) eben doch nicht alles beenden und aushängen kann, wenn die USV heruntergefahren wird. Liegt wahrscheinlich am upsmon Daemon. Auf jeden Fall habe ich immer den quotacheck auf der DS, die das USV abschaltet. Ich werde mal probieren ob ich den check nicht habe, wenn ich die USV laufen lasse bis die Battreien leer sind.

Gruss

tobi

 

[schmelix]

Bei mir läuft das Script absolut amok. Er versucht alle Dienste zich mal zu killen, ohne erfolg. Hat jemand ähnliche Phänomene bei der DS209


*Edit*

Ok wie ich jetzt herausgefunden habe liegt das Problem am "tollen" mysql init script, wenn ich es raus nehme läuft er mir zumidestens nicht amok.

Er unmounted mir /volume1, worüber er sich dann auch lautstark beschwert und mir ne Mail schickt , es laufen aber noch einige Prozesse die er nicht killt. Unter anderem der, apache postgres und der crond


Er schaltet sich daher auch nicht ab.



PS: Kann man das blöde Piepsen disablen? Ich habe ein initscript gefunden dass das Piepsen unterdrückt. Eine Lösung ist das aber nicht wirklich.

 

[jahlives]

Welches Script hast du denn, das amok läuft? Wenn es nicht um die Sache mit dem USV geht, dann solltest du für dein Problem einen eigenen Thread aufmachen

 

[schmelix]

Welches Script hast du denn, das amok läuft? Wenn es nicht um die Sache mit dem USV geht, dann solltest du für dein Problem einen eigenen Thread aufmachen

Habe den safemode Auszug aus der /usr/syno/bin/synoups verwendet. Hier haben ja einige, unter anderm goetz, geschrieben das die DS über einen cron sauber runter fährt.

Das tut sie bei mir eben nicht

 

[goetz]

Hallo,
wie hast Du es getestet, per ssh/telnet? Es läuft bei mir sauber als cronjob unter root. Abschalten soll sie gar nicht. Wozu willst Du das script nutzen?

Gruß Götz

 

[schmelix]

Hallo,
wie hast Du es getestet, per ssh/telnet? Es läuft bei mir sauber als cronjob unter root. Abschalten soll sie gar nicht. Wozu willst Du das script nutzen?

Gruß Götz

Als root cron. Mit dem abschalten ist wohl richitg wie ich gerade lese.

Wie so viele habe ich die DS an einer schaltbaren Steckdose, in meinem fall eine die ich über Netzwerk ansprechen kann, und eben auch die damit verbundenen Probleme die DS wieder autoamtisch starten zu lassen nach dem der Strom weg war.

 

[Great Gatsby]

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

Eine Verständnisfrage: Das ist das Skript, das die DiskStation in den "abschaltsicheren" Modus versetzt?

Folgendes habe ich ausprobiert: Ich möchte meine DS106j, die ja kein zeitgesteuertes Hardware-On unterstützt, mit diesem Skript in den "abschaltsicheren" Modus versetzen, dann mit einer zeitgeschalteten Steckdose die Stromzufuhr unterbrechen und später wieder aufnehmen, um so die DS106j auch zeitgesteuert wieder zu starten.

Ich habe also das Skript in das home-Verzeichnis des admins gelegt, es mit chmod +x S99ShutdownScript.sh (so der Dateiname) ausführbar gemacht und es ausgeführt, woraufhin folgende Ausgabe erscheint:

DiskStation> sh S99ShutdownScript.sh
S99ShutdownScript.sh: S99ShutdownScript.sh: 2: SYSLOG: not found
killall: mplayer: no process killed

Ist das normal? Das anschließende Booten nach Unterbrechung der Stromzufuhr dauert gefühlt etwas länger als normal, so dass ich nicht sicher bin, ob nicht doch ein File System Check durchgeführt wird ...

Oder habe ich diesen Thread komplett mißverstanden, etwa, weil das ganze nur mit USV funktioniert oder ähnlich?

 

[goetz]

Hallo,

Eine Verständnisfrage: Das ist das Skript, das die DiskStation in den "abschaltsicheren" Modus versetzt?

Ja.
Wenn Du Dein script von Hand ausführst kann es nicht richtig funktionieren. Es werden alle Systemdienste gestoppt, also auch ssh/telnet, und die ausführende shell beendet, somit auch Dein script. Es kann also die umounts nicht mehr ausführen und die DS startet mit einem quotacheck (dauert).
Du kannst es aber per

S99ShutdownScript.sh &

starten, damit bleibt es im Hintergrund am laufen. Es ist durch, wenn die Status LED aus geht.

Gruß Götz

 

[jahlives]

Und das Script keinesfalls unter /usr/syno/etc.defaults/rc.d oder /opt/etc/init.d anlegen. Das wird sonst lustig

 

[Great Gatsby]

Du kannst es [das Skript] aber per

S99ShutdownScript.sh &

starten, damit bleibt es im Hintergrund am laufen. Es ist durch, wenn die Status LED aus geht.

Hallo Götz,

vielen Dank! Mit Deiner Erklärung verstehe ich diesen Thread jetzt endlich ganz. - Eine letzte Frage, gehört das & dann auch in den entsprechenden crontab-Eintrag, also

30     22     *     *     *     root     /bin/sh /volume1/homes/admin/S99ShutdownScript.sh &

? - Oder funktioniert es da ohne & ?

Nochmals vielen Dank!

 

[Great Gatsby]

Und das Script keinesfalls unter /usr/syno/etc.defaults/rc.d oder /opt/etc/init.d anlegen. Das wird sonst lustig

Hmm, vermutlich ähnlich lustig wie "@reboot reboot" in der crontab (wenn crond auf der DiskStation "@reboot" verarbeiten könnte) ...

 

[goetz]

Hallo,
in der crontab brauchst Du das & nicht, jeder Job startet in seiner eigenen shell.

Gruß Götz

 

[Great Gatsby]

Ein weiteres Mal vielen Dank! Das Skript wird anscheinend nun ausgeführt, allerdings piept die DiskStation daraufhin bis zum Abschalten durch die zeitgeschaltete Steckdose etwa alle 2 Sekunden und die LEDs gehen auch nicht aus, solange die Stromzufuhr nicht unterbrochen wird.

Dem System-Protokoll entnehme ich Folgendes:

Warning         2010/08/10 06:31:41	admin	System booted up from an improper shutdown.
Information	2010/08/10 06:31:14	admin	Windows file service was started.
Information	2010/08/10 06:30:32	admin	System started to boot up.
Error	        2010/08/09 23:31:13	admin	Volume [1] was crashed.
Information	2010/08/09 23:31:12	admin	System successfully started Web Station service.
Information	2010/08/09 23:31:12	admin	System successfully started Download Station service.
Information	2010/08/09 23:31:12	admin	FTP service was started.
Information	2010/08/09 23:30:45	admin	Windows file service was started.
Information	2010/08/09 23:30:40	admin	System successfully stopped Web Station service.
Information	2010/08/09 23:30:40	admin	System successfully stopped Download Station service.
Information	2010/08/09 23:30:39	admin	FTP service was stopped.
Information	2010/08/09 23:30:19	admin	Windows file service was stopped.

Wie man aus dem LOG entnehmen kann, wird das Skript um 23.30 Uhr per cronjob ausgeführt, um 6.30 Uhr morgens stellt die Steckdose die Stromzufuhr wieder her. Soweit läuft alles wie geplant. Nur: Aus irgendeinem Grund werden die beendeten Dienste nach 40 Sekunden Laufzeit des Abschaltscripts wieder gestartet ... Habt Ihr vielleicht eine Idee, woran das liegen könnte?

 

[jahlives]

Waren denn die erwähnten Dienste auch wirklich erreichbar?

 

[Great Gatsby]

Waren denn die erwähnten Dienste auch wirklich erreichbar?

Das werde ich beim nächsten geplanten Abschalten ausprobieren. Gibt es darüber hinaus irgendwo auf der Station ausführlichere Logs als die, die man auch über das Web-Interface bekommt?

 

[jahlives]

Das ausführlichste Log ("Rohdaten") erreichst du via CLI (telnet oder ssh) unter /var/log/messages.

 

[itari]

Das ausführlichste Log ("Rohdaten") erreichst du via CLI (telnet oder ssh) unter /var/log/messages.

Die Logs im DS-Manager sind verschieden von der /var/log/messages und nochmals verschieden von denen, die Webserver und andere Server ablegen könnten.

Ich habe verschieden Sichten auf die Logs in mein AdminTool integriert (alle die, die mich halt interessiert haben); sind allerdings ein wenig verstreut, je nach Thema halt in anderen Funktionsbereichen; Beispiel: ich habe ein crond-log und das ist bei der crontab-Funktion.

Itari

 

[Great Gatsby]

Vielen Dank, jahlives und itari, für Eure Antworten.

@jahlives: Ich habe die Dienste der DiskStation mal während des oben beschriebenen "Dauerpiepens" durchprobiert:

- Das Webinterface erscheint nicht
- Auch mit SSL kommt man nicht auf die Station
- Der FTP-Server antwortet hingegen immerhin mit einer Login-Aufforderung, danach geht es aber mit einer Fehlermeldung über nicht ausreichendes RAM (ich glaube, es war "531") weiter

@itari: Danke, auf das AdminTool hätte ich eigentlich auch kommen können.

Hier mal der Auszug aus /var/log/messages für den Zeitraum eines Aus- und Anschaltens:

Aug 10 23:30:05 root: /usr/syno/etc/rc.d/S98findhostd.sh stop findhostd
Aug 10 23:30:09 synoaudiod: synoaudiod.cpp:502 synoaudiod exit
Aug 10 23:30:16 ssctl: services.cpp:563:Kill(): vsctrld is not running.
Aug 10 23:30:17 ssctl: ssctl.cpp:96:ClearSSTmpResource(): Get no service info
Aug 10 23:30:22 scheduler: scheduler.c (1607) Got signal. Die gracefully.
Aug 10 23:30:22 scheduler: scheduler.c (1625) rTorrent is killed.
Aug 10 23:30:27 kernel: fs_close_all_files: force to close file c1820f40
Aug 10 23:30:27 kernel: fs_close_all_files: force to close file c1cf2840
Aug 10 23:30:27 kernel: fs_close_all_files: force to close file c04722e0
Aug 10 23:30:27 kernel: fs_close_all_files: force to close file c1765840
Aug 10 23:30:27 kernel: sys_umount: force unmount success
Aug 10 23:30:29 scemd: modules/raid_data_volume_check.c:812 Volume /volume1 crashed, mount it read-only
Aug 10 23:30:40 scemd: volume_remount.c:40 Failed to remount '/volume1' to 'ro', WEXITSTATUS(err) = 255, err = 65280
Aug 10 23:30:40 scemd: volume_crashed_handler.c:40 Failed to remount '/volume1' to read-only
Aug 10 23:30:47 synorcd: hw_raytac.c (126) failed to open /dev/usb/hiddev5 (No such device).
Aug 10 23:30:54 ftpd[3892]: autoblock_is_enabled.c:25 ErrSLIBFileLock() failed!! file=[/etc/synoinfo.conf], synoerr=[0x0400]
Aug 10 23:31:13 scemd: modules/raid_data_volume_check.c:885 /volume1 state changes from 0 to 3.
Aug 11 06:30:34 kernel: eth0: network connection up using port A
Aug 11 06:30:34 kernel:     speed:           1000
Aug 11 06:30:34 kernel:     autonegotiation: yes
Aug 11 06:30:34 kernel:     duplex mode:     full
Aug 11 06:30:34 kernel:     flowctrl:        symmetric
Aug 11 06:30:34 kernel:     role:            slave
Aug 11 06:30:34 kernel:     irq moderation:  disabled
Aug 11 06:30:34 kernel:     scatter-gather:  enabled
Aug 11 06:30:34 kernel:     tx-checksum:     enabled
Aug 11 06:30:34 kernel:     rx-checksum:     enabled
Aug 11 06:30:35 s00_synocheckfstab: system_blk_dev_readahead_set.c:35 Failed to set '/dev/hda3''s readahead to 2048d
Aug 11 06:30:35 s00_synocheckfstab: s00_synocheckfstab.c:62 Failed to set RA on [/dev/hda3]
Aug 11 06:30:36 kernel: EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
Aug 11 06:30:37 scemd: scemd.c:114 fan_type=0, raid_type=0, led_type=0, thermal_type=0, fanctrl_type=0, auto_poweron_type=0, dual_power_type=0, usbcopy_type=0, fan_number=0, ebox_type=1, pis_type=0, rtc_type=0
Aug 11 06:30:37 scemd: modules/mapping_fan.c:197 Default fan type FAN_UNKNOWN is used.
Aug 11 06:30:37 scemd: modules/disk_hibernation.c:90 Force hibernation enable, idle minutes 10
Aug 11 06:30:38 synoprint: printer_device_open.c:16 bad parameter.
Aug 11 06:30:39 synousbdisk: RCClean succeeded
Aug 11 06:30:45 kernel: PCI: 00:0e.2 PCI cache line size set incorrectly (0 bytes) by BIOS/FW.
Aug 11 06:30:45 kernel: PCI: 00:0e.2 PCI cache line size corrected to 32.
Aug 11 06:30:45 kernel: USB_DEVICE: This is hub. No need to call_policy_interface.
Aug 11 06:30:46 kernel: USB_DEVICE: This is hub. No need to call_policy_interface.
Aug 11 06:30:46 kernel: USB_DEVICE: This is hub. No need to call_policy_interface.
Aug 11 06:30:47 kernel: usb.c (1046) Already got printer. Skip other devices.
Aug 11 06:30:48 kernel: Unknown model: 0
Aug 11 06:30:48 syno_hdd_util: Model:[ST3750640A], Firmware:[3.AAE], S/N:[5QD5ADTW] in [/dev/hda] is not ssd
Aug 11 06:30:49 ddnsd: main(ddnsd.c:1874):  not enable DDNS, shutdown daemon
Aug 11 06:30:56 synoprint: printer_enable_ext.c:124 printer driver infomation cleared.
Aug 11 06:30:56 kernel: set lp0 stop as 0
Aug 11 06:30:56 synoprint: printer_support_post_script.c:88 lp0 support commands: CMD:BJL,BJRaster3,BSCCe [0]
Aug 11 06:31:26 synorcd: hw_raytac.c (126) failed to open /dev/usb/hiddev5 (No such device).

So richtig erschließt sich mir daraus nicht, warum die Station in ein Blinken und Dauerpiepen übergeht, statt sich in den "abschaltsicheren" Modus zu begeben ...

 

[goetz]

Hallo,
das Problem dürfte an

scemd: modules/raid_data_volume_check.c:812 Volume /volume1 crashed, mount it read-only

liegen, beim crash des Filesystems piept die DS. Warum volume1 als crashed erkannt wird weiß ich nicht. Welche Firmware hast Du drauf? scemd ist leider ein Buch mit 7 Siegeln, ein alles überwachender daemon.

Gruß Götz