[2. Sammelthema] Probleme mit Standby Funktion

Zitat von "MatthiasM"

Was passiert da und warum?

Zitat von "MatthiasM"

Beim nächtlichen Testlauf war außer meinem Bürolaptop mit Putty

Niemals nie nicht sollte man so einen Test zwischen 3 und 4Uhr machen. Genau da laufen die meissten Wartungs-Routinen. Poste mal den Inhalt von

/tmp/cron/crontabs/admin

Zitat von "Tossy"

ok, doch insgesamt ist laut Log das Phänomen "BT und QCloud" wohl leider nicht erklärbar - oder?

Die Sache mit qcloud_cli noch eher als das hcitool. Dazu bräuchte ich mal die Inhalte von

/tmp/cron/crontabs/admin
/tmp/.bluetoothd.log

Zitat von "hungertuch"

Na hoffentlich kommt hier bald ein durchschlagender Lösungsvorschlag vom Herssteller.

Den kann ich dir auch geben - NAS ausschalten.

Zitat von "hungertuch"

gem. Produkt Werbung) ist eine generelle Herstellerlösung für mich von Nöten.

Auch die Hersteller von Mainboards haben in ihren Spezifikationen einen Plattenstandby stehen. Windows und wahrscheinlich Mac-OS auch. Noch nie hat irgendwer diese Fimen aufgefordert dies auch umzusetzen. Warum?? Und warum soll jetzt ausgerechnet QNAP dies tun. Zumal bei QNAP die Platten ja in den Ruhezustand gehen wenn die Voraussetzungen erfüllt sind (keine Schreib-/Lesezugriffe auf die Platten). Bei Windows habe ich in all den Jahren, die ich es nutze, noch nie eine Platte schlafen gesehen.

Zitat von "dr_mike"

Poste mal den Inhalt von

Code

/tmp/cron/crontabs/admin

login as: admin
admin@pollux-nas's password:
[~] # /tmp/cron/crontabs/admin
-sh: /tmp/cron/crontabs/admin: Permission denied
[~] #

Ich derf net warum? Bin ich der NASe als Admin noch nicht Gott genug..

Zitat von "hungertuch"

Wirkt auf mich wie hilfloses rumgestochere.
Da ich keine Ahnung von Konsole oder sonstigen administrativen Detailfunktionen habe (reiner Anwender ohne Fachkenntnis gem. Produkt Werbung) ist eine generelle Herstellerlösung für mich von Nöten.
Das Engagement in Ehren.

Genau so sehe ich das auch! Und tut mir leid, wenn ich aus meinem Ärger heraus, dem einen oder anderen etwas auf die Füße getreten bin.
Aber ich bin einfach nur sauer, das mit diesem -nicht gerade günstigem- Mist, nichts so richtig läuft. Gerade durfte ich wieder feststellen, das nach einer Nacht im Ruhemodus, die USB Ports mal wieder tot sind. Super... und dann kommt Qnap mit solch Aussagen , wie Kompatibilität. So ein Quatsch. Die Ports werden einfach im Ruhemodus ausgeschaltet und starten nicht wieder neu .
Sorry fürs etwas OT aber das musste einfach mal raus.

Aber zum Standby der PLatten: Ich hab mir jetzt fast die ganzen 30 Seiten hier durchgelesen und ich kann hungertuch nur recht geben, Lösungen gibst es keine, nur wahlloses rumprobiere. Mal soll es dies sein, mal das aber etwas konkretes gibt es nicht.
Und damit das nicht wieder falsch rüber kommt: Ich meine damit nicht die Leute, die hier versuchen zu helfen sondern mein Unmut geht eher an Qnap, die anscheinend auch nach Jahren nicht in der Lage sind, mal vernünftige Software auf die Beine zu stellen (ich hatte vor einigen Jahren schon mal eine,mit fast den gleichen Problemen).
Sinn so eines NAS soll ja eigentlich die Anwenderfreundlichkeit sein, das war auch mein Gedanke beim Kauf. Das Gegenteil ist eigentlich der Fall

Zitat von "christian"

Versuch es mal mit

Code

cat /tmp/cron/crontabs/admin

[~] # cat /tmp/cron/crontabs/admin
# m h dom m dow cmd
0 4 * * * /sbin/hwclock -s
0 3 * * * /sbin/vs_refresh
0 3 * * * /sbin/clean_reset_pwd
0-59/15 * * * * /etc/init.d/nss2_dusg.sh
0 3 * * 0 /etc/init.d/idmap.sh dump
10 15 * * * /usr/bin/power_clean -c 2>/dev/null
4 3 * * 3 /etc/init.d/backup_conf.sh
[~] #

Irgendwas auffälliges? Das einzige kurzfristig wiederkehrende ist dieses nss2_dusg.sh, muß (laut Suche) irgendwas von der Surveillance-Station sein (die ich nie aktiviert hatte), die bei einer 3.7.x (vielleicht 3.8.1 auch) buggyierweise bei Deaktivierung den Cronjob nicht löscht, das würde (ohne daß ich jetzt weiß, was das Skript tut) aber nur zu Aktivitäten/Aufwachen alle 15 Minuten führen. Alle anderen Sachen laufen einmal nächtlich jeden Tag oder gar nur einmal wöchentlich. Das alles erklärt nicht die ständigen 5-Sekunden-Intervalle, oder?...

Zitat von "tasar"

Ich hab mir jetzt fast die ganzen 30 Seiten hier durchgelesen

Scheinbar immer genau die Beiträge überlesen, die bestätigten, dass die Ursache beim User lag. Meinen Beitrag dazu hast du auch geflissentlich überlesen. Ich zitiere diesen gerne nochmal für dich:

Zitat von "dr_mike"

Auch die Hersteller von Mainboards haben in ihren Spezifikationen einen Plattenstandby stehen. Windows und wahrscheinlich Mac-OS auch. Noch nie hat irgendwer diese Fimen aufgefordert dies auch umzusetzen. Warum?? Und warum soll jetzt ausgerechnet QNAP dies tun. Zumal bei QNAP die Platten ja in den Ruhezustand gehen wenn die Voraussetzungen erfüllt sind (keine Schreib-/Lesezugriffe auf die Platten). Bei Windows habe ich in all den Jahren, die ich es nutze, noch nie eine Platte schlafen gesehen.

Zitat von "tasar"

Sinn so eines NAS soll ja eigentlich die Anwenderfreundlichkeit sein

An welcher Stelle wird für dich die Anwenderfreundlichkeit negativ beeinflusst wenn die Platten laufen? Im Übrigen mal Bilder von meinen NAS im Anhang, die gerade friedlich schlummern. Dies würden sie nicht tun, wenn es ein genereller FW-Bug wäre.

Zitat von "MatthiasM"

Irgendwas auffälliges?

Auffälliges ist nicht zu sehen. Aber schau dir mal die Zeilen 1 - 3 und 5 an. Das sind Zeitintensive Prozesse, die genau in dem Zeitbereich liefen, als du das Log gemacht hast. Gerade vs_refresh braucht je nach Datenmenge ne ganze Weile.

@ dr_mike, die Platten die jetzt in der Qnap sind, liefen vorher in einem Windows Server 2012 System und da gab es keine Probleme mit dem Standby der Platten. Natürlich sind die auch mal aufgewacht aber da war auch eine schreib oder lese Aktion dafür verantwortlich. Die Qnap schaltet die Platten aus um dann teilweise innerhalb einer Minute wieder hochzufahren. Länger als 30 Minuten waren die Platten bei mir noch nie im Schlummer Modus.
Auch mein Windows 10 Desktop PC macht nicht diese Probleme.
Und nein, ich mache die Anwenderfreundlichkeit natürlich nicht am Standby der Platten fest aber z.b. daran, dass bei mir die USB Ports nach längerem Ruhemodus nicht mehr aktiv sind (sowohl USB 2 als auch 3) und ich dann erst wieder Neustarten darf, damit z.b. die Tastatur oder meine Backupplatte funktioniert. Das die HD Station den HDMI Kontakt nach Ruhemodus oder einfach nur Ausschalten des TV verliert (ist seit Monaten bekannt und nichts passiert), das die Virtul. Station zumindest über die HTML5 Konsole nicht bedienbar ist weil derart träge, das man die Lust verliert usw. Das wird dann aber jetzt aber zu OT aber sind ja alles keine EInzelfälle, wie man hier und auch im engl. Forum nachlesen kann.
Ich bin vielleicht auch mit falschem Voraussetzungen beim Kauf ausgegangen: Ich dachte ich richte das Teil ein und läuft, ist aber leider nicht so.
Ich halte mich deshalb hier jetzt auch zurück und beobachte

Zitat von "tasar"

Das wird dann aber jetzt aber zu OT

Alle von dir angesprochenen Dinge außer Platten-Standby sind hier OT.

dr_mike,
mit den nächtlichen Wartungsprozessen hast Du recht, aber auch tagsüber ist da nie Ruhe, drum hab ich jetzt noch ein Log gezogen.

Ich nehme an, daß Du im Log diejenigen Zugriffe, die von "normalen" werktäglichen Usern im Netz stammen, erkennst, da werden jetzt am Sonntag Nachmittag sporadisch welche dazwischen sein. Was den Rest der Familie betrifft kann das nur r/w Zugriff auf Freigabe "Public" sein, sonst nix. (was ist dieses ganze chown-Zeugs am Anfang vom Log??)

Die mysteriöse Festplattenaktivität im 5-Sek.-Turnus habe ich jedenfalls rund um die Uhr, korreliert mit diesen Blöcken mit haufenweise

<7>[41539.810914] jbd2/md0-8(3196): WRITE block 2927926032 on md0 (8 sectors)<7>[41539.810968] md0_raid1(3171): WRITE block 11717907368 on sda3 (2 sectors)

Hier nochmal ein Log von jetzt sonntags nachmittags über 100 Durchläufe, und (Du siehst, die blöde NASe verschafft mir einen unfreiwilligen Crashkurs in Linux-Konsole, ich fühle mich zurückgeworfen in MS-DOS-Zeiten :mrgreen: ) ich habe mal die Prozessliste dazugepackt. Jetzt muß ich "nur noch" rausfinden, was diese beiden Burschen (die den erschlagend überwiegenden Teil des ersten Logs von heute nachts und auch den vom nachmittäglichen unter sich ausmachen) tun, wozu sie gut sind, in wessen Auftrag sie werkeln und warum die dauernd auf meinen Platten rumschraddeln..

3171 admin           SW  [md0_raid1]
 3196 admin           SW  [jbd2/md0-8]

Nachtrag: Der erste hat nach kurzem Querlesen über Google irgendwas mit dem RAID zu tun (naheliegend...), der zweite mit dem Journaling vom ext4.. Detektivarbeit...

lG Matthias

Zitat von "dr_mike"

....

Den kann ich dir auch geben - NAS ausschalten.

Das war jetzt wirkliche eine durchschlagender Vorschlag, wenn auch nicht konstruktiv. Aber das liegt in der IT oft auch im Auge des Betrachters.

Zitat von "dr_mike"

Auch die Hersteller von Mainboards haben in ihren Spezifikationen einen Plattenstandby stehen. Windows und wahrscheinlich Mac-OS auch. Noch nie hat irgendwer diese Fimen aufgefordert dies auch umzusetzen. Warum?? Und warum soll jetzt ausgerechnet QNAP dies tun. Zumal bei QNAP die Platten ja in den Ruhezustand gehen wenn die Voraussetzungen erfüllt sind (keine Schreib-/Lesezugriffe auf die Platten). Bei Windows habe ich in all den Jahren, die ich es nutze, noch nie eine Platte schlafen gesehen.

Und was ich gesehen habe, ist das mein Qnap TS-219 PII über Monate hin immer im Standby war (kleine Ausnahmen außen vor) wenn ich nicht darauf zugegriffen habe. :shock:
Das ist an rund 5 von 7 Tagen in der Woche der Fall.
Wir haben also beide noch nicht alles gesehen aber genau diesen Zustand möchte ich aber wiederherstellen bzw. wiedersehen. :x
Und diese Veränderung das das System nicht in Standby geht kam nicht durch mich.
Ich habe nichts geändert, ich habe nur die Firmware Updates installiert mit denen Sicherheitslücken oder Bugs entfernt werden sollten. :oops:

Ist das falsch? _hurted:

Zitat von "hungertuch"

Ich habe nichts geändert, ich habe nur die Firmware Updates installiert mit denen Sicherheitslücken oder Bugs entfernt werden sollten. :oops:

Ist das falsch? _hurted:

Manchmal offensichtlich ja.

Ist jedenfalls nicht exklusiv für Windows reserviert, auch Fritzboxler, NASennutzer etc. können manchmal ein Lied davon singen (siehe 4.2.0 "not clean...")
Ich schwanke immer zwischen "brav Updates unbedingt einspielen" und "never touch". Bei Kisten, die nicht nach außen exponiert sind, neige ich eher zu "never touch" (Siehe meine NASe mit 3.8.1), bei den Windoozen, die ins Netz rausdürfen kommt man nicht drum rum*, aber schwersten mit der Entscheidung tu ich mich bei der Fritzbox, weil sie zentral wichtig UND erstklassig nach außen exponiert ist....

lG Matthias

* PS.: hier werkeln aus verschiedenen Gründen auch noch sehr häufig eine XP-Kiste mit CAD, oft eine W2000-Kiste mit CAD und Büro, eine bald 22jährige NT4/W95-Kiste von 1994 für eine uralte CAD und sehr selten eine fast ein Vierteljahrhundert IT-Geschichte alte MS-DOS6/WfW3.11-Kiste von 1992 nur wegen einem exotischen Programmieradapter, der ab W95 nicht mehr gelaufen wäre...
lG Matthias

Zitat von "MatthiasM"

Jetzt muß ich "nur noch" rausfinden, was diese beiden Burschen (die den erschlagend überwiegenden Teil des ersten Logs von heute nachts und auch den vom nachmittäglichen unter sich ausmachen) tun, wozu sie gut sind, in wessen Auftrag sie werkeln und warum die dauernd auf meinen Platten rumschraddeln..

Die tun das, was sie von einem vorgelagerten Schreib-/Lesebefehl aufgetragen bekommen haben.
Das sind die Kernel-RAID-Treiber auch kurz das RAID-System genannt. Genau diese können aus jeglicher Betrachtung aussen vor gelassen werden. Deshalb filtere ich diese auch gleich als erstes aus (siehe dein Log gefiltert im Anhang).
Daraus ergibt sich ein überwiegender Anteil an chown-Befehlen. Diese scheinen im Zusammenhang mit MySQL-Datenbank und damit vermutlich mit dem Mailserver zu stehen. Sie könnten aber auch von NFS-Verbindungen in Verbindung mit der Squash Option stammen.
Habe ich hier so jedoch noch in keinem einzigen Log bisher gesehen.

Hmm, Mailserver hab ich keinen laufen (oder meinst Du den "Minimalserver" für die Benachrichtigungen) - solll ich das Xmail-Paket komplett deinstallieren? oder irgendeinen DIenst (MySQL-Server gezielt einmal aktivieren und wieder deaktivieren), und die ganzen chown & Co hatte ich heute nachts NICHT, und trotzdem alle 5 Sekunden HDD-Zugriff.... also gefiltert wäre mein nächtliches Logfile leer gewesen.

Soll ich irgendeinen prozess killen? den qwatchdogd, der wäre das einzige offensichtliche, was im 5-Sekunden-Takt was tut...
... ausprobiert, nein, nix hat sich geändert.....

Hmmm, wie weiter? Ich deinstalliere jetzt Xmail, starte und stoppe den MySQL-Manager und starte dann die Kiste neu, ich rechne fast mit keiner Änderung....

bis später :-/

[Nachtrag:] ... war irgendwie klar... Nix hat sich geändert....

[uuuund update vom Vormittag] ...ich habe der Kiste "zugeschaut" wie sie ihre nächtlichen 3-Uhr-Wartungsjobs gemacht hat und danach plötzlich, ich weiß wie immer NICHT, was JETZT wieder anders ist, denn auf einmal - :shock: die Kiste geht in Standby....

Meine ganze EIn-Ausschalterei UND Xmail deinstalliert UND die nächtlichen Wartungsläufe zusammen waren'S wohl. Ich beobachte das ganze jetzt mal (und vergleiche crontab und laufende Prozesse mit meinen vorigen....)...

Hallo zusammen,

ich lasse gerade den Test blkdevMonitor.sh laufen und habe eine Grundsätzliche Frage dazu.

Ist es so das bei dem Test in der Zeile in der ...dirtied inode... auftaucht dahinter das in Klammern auch der "Fehler" sozusagen ist?

Nein, das ist die Inode mit zugeordneter Datei, falls ermittelbar. Das verursachende Programm steht vor "dirtied inode".

Ich habe jetzt mal einen Test mit nur 10 Durchgängen gemacht weil ich irgendwie das Gefühl habe das er bei mir ziemlich lange dauert -so was ich bisher bei den anderen gelesen habe.

Kann mir mal Bitte jemand erklären was man draus lesen kann?

Und gibt es ein Verzeichnis wo ich den Verursacher entschlüsseln kann?
Weil wenn ich richtig verstanden habe wäre ja vor dem " dirtied inode " sed was hier irgendwas verhindert.

Vielen Dank im voraus

Bitte teste mal das hier anhängende Tool. Ich habe es mal um cachedev erweitert.

Hier ist das Ergebnis mit dem erweiterten Tool

Schade, cachedev scheint nicht involviert zu sein. Damit ist erstmal nicht herauszufinden, wer das sed Kommando anstösst.
Könntest du bitte mal noch die Ausgabe von

ps -ef
lsof | grep crontab

posten?