Ubuntu NAS crasht om de week

zondag 23 juni 2019 18:16

iPL dev

Alt+SysRq+r zou je keyboard in raw moeten krijgen en dan zouden normale toetsencombinaties weer moeten werken, maar dat heeft eigenlijk geen zin als er geen X op draait (dan staat ie namelijk niet in de verkeerde mode). Probeer nog wat te pielen maar reboot anders gewoon die bak, log in op de fysieke console, run

setterm -blank 0
setterm -powersave off
setterm -store

Op deze manier blijft het scherm (de output) aan staan dus kan je tenminste zien wat het laatste is wat de machine gedaan heeft. Dat kan dus een bepaalde logregel zijn die niet naar disk geschreven is vanwege redenen, of dus iets raars in de output van mijn of een ander monitoringscript. Je moet dan dus nog wel dat script starten, of naar je syslog-terminal switchen (doorgaans ctrl+alt+f12). Ik zou persoonlijk eerst voor je syslog gaan, dikke kans dat je daar iets nuttigs in ziet. Dan lekker laten staan (scherm kan uit/afgekoppeld) en als 'ie weer hangt zou je wat meer moeten kunnen zien.

Alle reacties

Acties:

0 Henk 'm!

MAX3400

XBL: OctagonQontrol

WDC Green is toch helemaal niet geschikt voor NAS-taken? Ik dacht dat je daar de firmware van moest aanpassen / flashen om allerlei "green features" uit te schakelen en de disks 24/7 te kunnen gebruiken.

Mijn advertenties!!! | Mijn antwoorden zijn vaak niet snowflake-proof

zondag 23 juni 2019 18:23

Acties:

0 Henk 'm!

Arunia

@MAX3400 dat had te maken met het parkeren van de koppen wat heel snel gebeurde. Dit kon je inderdaad uit de firmware halen.
Ikzelf heb net de laatste 1,5TB green uit de server gehaald. Deze had meer dan een miljoen keer de kop geparkeerd.

still going strong btw.

zondag 23 juni 2019 18:32

Acties:

+1 Henk 'm!

zondag 23 juni 2019 18:37

Topicstarter

@MAX3400 en @Arunia , kan dat ook een probleem zijn als het OS hier niet op draait?

Acties:

0 Henk 'm!

TommieW

Numa numa.

Ja, dat zou kunnen. Ik heb weleens gezien dat een machine hangt omdat er één (niet-OS) disk niet bereikbaar is.

Heb je de mogelijkheid om een scherm aan de machine te hangen? Misschien dat er op TTY1 nog iets van een melding te zien is. Wat je ook kan doen is een toetsenbord eraan hangen en kijken of (wanneer het zich weer voordoet) je de capslock/numlock nog uit en aan kan doen. Als dat nog lukt, dan draait de kernel nog door en is het wellicht een netwerk issue.

Edit:
Hoe zien de SMART waarden van alle disks eruit? En dan met name de current pending sectors, uncorrectable sectors en CRC error count.

[ Voor 14% gewijzigd door TommieW op 23-06-2019 18:41 ]

1700X@3,9GHZ - Asus Crosshair VI Hero - 32GB Corsair LPX - GTX 1070Ti
iPhone 13 Pro Max - Macbook Pro 16" M1 Pro

zondag 23 juni 2019 18:42

Acties:

0 Henk 'm!

temp00

Als het kan ben ik lam

Kan je als tussenoplossing niet gewoon een dagelijkse reboot inlassen?

code:

1 2	sudo crontab -e 00 23 * * * /sbin/reboot

(dagelijkse reboot om 23.00 uur)

♠ REPLY CODE ALPHA ♠ 9800X3D, 32GB @ 6000, 980 Pro 2TB, RTX 5070Ti, MPG271QRX OLED @ 360HZ ♠ Overwatch ♠

zondag 23 juni 2019 18:42

Acties:

0 Henk 'm!

Arunia

Ik zou eens de smart waardes van alle schijven uit lezen. Daar kan iets uitkomen.

zondag 23 juni 2019 18:42

Acties:

0 Henk 'm!

ThinkPad

MAX3400 schreef op zondag 23 juni 2019 @ 18:16:
WDC Green is toch helemaal niet geschikt voor NAS-taken? Ik dacht dat je daar de firmware van moest aanpassen / flashen om allerlei "green features" uit te schakelen en de disks 24/7 te kunnen gebruiken.

offtopic:
Waar jij op doelt is met hardware RAID, dus echt een RAID-controller. Software RAID kan wel, heb in mijn Synology NAS ook al 3-4 jaar 2 stuks WD Green in RAID1 draaien en gaat prima.

[ Voor 3% gewijzigd door ThinkPad op 23-06-2019 18:43 ]

zondag 23 juni 2019 19:43

Acties:

0 Henk 'm!

zondag 23 juni 2019 19:44

Topicstarter

TommieW schreef op zondag 23 juni 2019 @ 18:37:
Ja, dat zou kunnen. Ik heb weleens gezien dat een machine hangt omdat er één (niet-OS) disk niet bereikbaar is.

Heb je de mogelijkheid om een scherm aan de machine te hangen? Misschien dat er op TTY1 nog iets van een melding te zien is. Wat je ook kan doen is een toetsenbord eraan hangen en kijken of (wanneer het zich weer voordoet) je de capslock/numlock nog uit en aan kan doen. Als dat nog lukt, dan draait de kernel nog door en is het wellicht een netwerk issue.

Edit:
Hoe zien de SMART waarden van alle disks eruit? En dan met name de current pending sectors, uncorrectable sectors en CRC error count.

Ik heb die mogelijkheid wel als het niet een verkeerd moment is, ik kan dan een kabel naar de tv leggen en een toetsenbord eraan hangen, zal ik volgende keer proberen!

Ik heb net even de SMART waarden bekeken, ik zie eigenlijk alleen iets geks bij de SSD die een uncorrectable-ecc-count van 5845 heeft. De rest van de waarden staan hieronder:

SSD:

code:

Abort Self-Test Available: yes
Short Self-Test Polling Time: 1 min
Extended Self-Test Polling Time: 48 min
Conveyance Self-Test Polling Time: 2 min
Bad Sectors: 0 sectors
Powered On: 3.9 years
Power Cycles: 145
Average Powered On Per Power Cycle: 9.9 days
Temperature: 37.0 C
Attribute Parsing Verification: Good
Overall Status: GOOD
ID# Name                        Value Worst Thres Pretty      Raw            Type    Updates Good Good/Past
  1 raw-read-error-rate          95    95    50   8600221339  0x9bf69c000200 old-age online  yes  yes
  5 reallocated-sector-count    100   100     3   0 sectors   0x000000000000 prefail online  yes  yes
  9 power-on-hours               61    61     0   3.9 years   0x15870000d675 old-age online  n/a  n/a
 12 power-cycle-count           100   100     0   145         0x910000000000 old-age online  n/a  n/a
171 program-fail-count          100   100     0   0           0x000000000000 old-age online  n/a  n/a
172 erase-fail-count            100   100     0   0           0x000000000000 old-age online  n/a  n/a
174 attribute-174               n/a   n/a     0   n/a         0x7c0000000000 old-age offline n/a  n/a
177 wear-leveling-count         n/a   n/a     0   96          0x600000000000 old-age offline n/a  n/a
181 program-fail-count-total    100   100     0   0           0x000000000000 old-age online  n/a  n/a
182 erase-fail-count-total      100   100     0   0           0x000000000000 old-age online  n/a  n/a
[b]187 reported-uncorrect          100   100     0   0 sectors   0x000000000000 old-age online  n/a  n/a[/b]
189 high-fly-writes              37    42     0   55837327397 0x25002a000d00 old-age offline n/a  n/a
194 temperature-celsius-2        37    42     0   37.0 C      0x25002a000d00 old-age online  n/a  n/a
195 hardware-ecc-recovered      102   102     0   8600221339  0x9bf69c000200 old-age offline n/a  n/a
196 reallocated-event-count     100   100     3   0           0x000000000000 prefail online  yes  yes
201 soft-read-error-rate        102   102     0   8600221339  0x9bf69c000200 old-age offline n/a  n/a
204 shock-count-write-open      102   102     0   8600221339  0x9bf69c000200 old-age offline n/a  n/a
230 head-amplitude              100   100     0   n/a         0x640000000000 prefail online  n/a  n/a
231 temperature-celsius          93    93    10   0.0 C       0x000000000000 prefail online  yes  yes
233 power-on-seconds-2          n/a   n/a     0   n/a         0x802700000000 old-age online  n/a  n/a
[b]234 uncorrectable-ecc-count     n/a   n/a     0   5845 sectors 0xd51600000000 old-age online  n/a  n/a[/b]
241 total-lbas-written          n/a   n/a     0   196.125 GB  0xd51600000000 old-age online  n/a  n/a
242 total-lbas-read             n/a   n/a     0   195.119 GB  0xb71600000000 old-age online  n/a  n/a

WD Green 1:

code:

Device: sat16:/dev/sdb
Type: 16 Byte SCSI ATA SAT Passthru
Size: 2861588 MiB
Model: [WDC WD30EZRX-00D8PB0]
Serial: [WD-WCC4NEUA56DC]
Firmware: [80.00A80]
SMART Available: yes
Quirks:
Awake: yes
SMART Disk Health Good: yes
Off-line Data Collection Status: [Off-line data collection activity was suspended by an interrupting command from host.]
Total Time To Complete Off-Line Data Collection: 40680 s
Self-Test Execution Status: [The previous self-test routine completed without error or no self-test has ever been run.]
Percent Self-Test Remaining: 0%
Conveyance Self-Test Available: yes
Short/Extended Self-Test Available: yes
Start Self-Test Available: yes
Abort Self-Test Available: yes
Short Self-Test Polling Time: 2 min
Extended Self-Test Polling Time: 408 min
Conveyance Self-Test Polling Time: 5 min
Bad Sectors: 0 sectors
Powered On: 4.0 years
Power Cycles: 137
Average Powered On Per Power Cycle: 10.8 days
Temperature: 37.0 C
Attribute Parsing Verification: Good
Overall Status: GOOD
ID# Name                        Value Worst Thres Pretty      Raw            Type    Updates Good Good/Past
  1 raw-read-error-rate         200   200    51   0           0x000000000000 prefail online  yes  yes
  3 spin-up-time                179   174    21   6.0 s       0x911700000000 prefail online  yes  yes
  4 start-stop-count             82    82     0   18075       0x9b4600000000 old-age online  n/a  n/a
  5 reallocated-sector-count    200   200   140   0 sectors   0x000000000000 prefail online  yes  yes
  7 seek-error-rate             200   200     0   0           0x000000000000 old-age online  n/a  n/a
  9 power-on-hours               52    52     0   4.0 years   0x7e8a00000000 old-age online  n/a  n/a
 10 spin-retry-count            100   100     0   0           0x000000000000 old-age online  n/a  n/a
 11 calibration-retry-count     100   100     0   0           0x000000000000 old-age online  n/a  n/a
 12 power-cycle-count           100   100     0   137         0x890000000000 old-age online  n/a  n/a
192 power-off-retract-count     200   200     0   43          0x2b0000000000 old-age online  n/a  n/a
193 load-cycle-count            103   103     0   292106      0x0a7504000000 old-age online  n/a  n/a
194 temperature-celsius-2       113   105     0   37.0 C      0x250000000000 old-age online  n/a  n/a
196 reallocated-event-count     200   200     0   0           0x000000000000 old-age online  n/a  n/a
[b]197 current-pending-sector      200   200     0   0 sectors   0x000000000000 old-age online  n/a  n/a[/b]
198 offline-uncorrectable       200   200     0   0 sectors   0x000000000000 old-age offline n/a  n/a
[b]199 udma-crc-error-count        200   200     0   0           0x000000000000 old-age online  n/a  n/a[/b]
200 multi-zone-error-rate       200   200     0   0           0x000000000000 old-age offline n/a  n/a

WD green 2:

code:

Device: sat16:/dev/sdc
Type: 16 Byte SCSI ATA SAT Passthru
Size: 2861588 MiB
Model: [WDC WD30PURX-64P6ZY0]
Serial: [WD-WCC4N3UJFAJD]
Firmware: [80.00A80]
SMART Available: yes
Quirks:
Awake: yes
SMART Disk Health Good: yes
Off-line Data Collection Status: [Off-line data collection activity was completed without error.]
Total Time To Complete Off-Line Data Collection: 37920 s
Self-Test Execution Status: [The previous self-test routine completed without error or no self-test has ever been run.]
Percent Self-Test Remaining: 0%
Conveyance Self-Test Available: yes
Short/Extended Self-Test Available: yes
Start Self-Test Available: yes
Abort Self-Test Available: yes
Short Self-Test Polling Time: 2 min
Extended Self-Test Polling Time: 380 min
Conveyance Self-Test Polling Time: 5 min
Bad Sectors: 0 sectors
Powered On: 1.9 years
Power Cycles: 84
Average Powered On Per Power Cycle: 8.5 days
Temperature: 38.0 C
Attribute Parsing Verification: Good
Overall Status: GOOD
ID# Name                        Value Worst Thres Pretty      Raw            Type    Updates Good Good/Past
  1 raw-read-error-rate         200   200    51   0           0x000000000000 prefail online  yes  yes
  3 spin-up-time                182   177    21   5.9 s       0x031700000000 prefail online  yes  yes
  4 start-stop-count             97    97     0   3221        0x950c00000000 old-age online  n/a  n/a
  5 reallocated-sector-count    200   200   140   0 sectors   0x000000000000 prefail online  yes  yes
  7 seek-error-rate             200   200     0   0           0x000000000000 old-age online  n/a  n/a
  9 power-on-hours               77    77     0   1.9 years   0xa54200000000 old-age online  n/a  n/a
 10 spin-retry-count            100   100     0   0           0x000000000000 old-age online  n/a  n/a
 11 calibration-retry-count     100   253     0   0           0x000000000000 old-age online  n/a  n/a
 12 power-cycle-count           100   100     0   84          0x540000000000 old-age online  n/a  n/a
192 power-off-retract-count     200   200     0   33          0x210000000000 old-age online  n/a  n/a
193 load-cycle-count            199   199     0   3365        0x250d00000000 old-age online  n/a  n/a
194 temperature-celsius-2       112   107     0   38.0 C      0x260000000000 old-age online  n/a  n/a
196 reallocated-event-count     200   200     0   0           0x000000000000 old-age online  n/a  n/a
[b]197 current-pending-sector      200   200     0   0 sectors   0x000000000000 old-age online  n/a  n/a[/b]
[b]198 offline-uncorrectable       200   200     0   0 sectors   0x000000000000 old-age offline n/a  n/a[/b]
[b]199 udma-crc-error-count        200   200     0   0           0x000000000000 old-age online  n/a  n/a[/b]
200 multi-zone-error-rate       200   200     0   0           0x000000000000 old-age offline n/a  n/a

[ Voor 0% gewijzigd door Jlo88 op 23-06-2019 19:46 . Reden: Formatting ]

Acties:

0 Henk 'm!

maandag 24 juni 2019 00:18

Topicstarter

temp00 schreef op zondag 23 juni 2019 @ 18:42:
Kan je als tussenoplossing niet gewoon een dagelijkse reboot inlassen?
code:
1
2
sudo crontab -e
00 23 * * * /sbin/reboot
(dagelijkse reboot om 23.00 uur)

Daar heb ik ook aan zitten denken maar dit lost niet echt het probleem op denk ik. Zo'n NAS moet toch 24/7 kunnen draaien voor een jaar achter elkaar zonder te crashen zou je zeggen?

Acties:

0 Henk 'm!

maandag 24 juni 2019 08:33

iPL dev

Ik denk persoonlijk ook aan een I/O issue maar dat kan lastig troubleshooten zijn als het zo lang duurt tussen fouten. Ook al is er niks met je schijven kan bijvoorbeeld je controller gaar zijn. Als je op een fysieke console iets als dit kan laten draaien (als root):

while true; do echo -n "$(date +%Y%m%d-%H:%M:%S) "; cat /proc/[0-9]*/status 2>/dev/null | grep -P "^State:\s+D" | wc -l; sleep 1; done

zie je elke seconde hoeveel processen in state D (disk sleep) zitten. Als het een I/O-issue is zal je hoogstwaarschijnlijk hoge getallen gaan zien op het moment dat het misgaat. Normaal zal het een getal onder de vijf zijn ofzo, maar dat ligt helemaal aan wat je systeem allemaal doet. Ook als de machine veel met I/O bezig is zal dat nummer omhoog gaan. Als je echt I/O problemen hebt zullen veel processen in die state blijven hangen en gaat het hoge nummer dus niet meer omlaag.

In de tussentijd kan je ook kijken of je iets in je syslog (niet alleen kernel log) kan vinden rond die tijd, misschien zie je wel steeds hetzelfde proces wat logregels wegschrijft rond de tijd dat het misgaat. Daadwerkelijke logmessages van het moment zelf zul je waarschijnlijk niet tegenkomen, afhankelijk van wat het probleem is en hoe de machine hangt.

Edit2: heb je een swapfile/partitie, en hoe vol zit je geheugen doorgaans?

Edit: Ik had tijd over, je kan in plaats van dat commando hierboven ook dit script gebruiken voor misschien wat meer inzicht

Python:

#!/usr/bin/env python3
from glob import glob
from datetime import datetime
from time import sleep

while True:
    states = {"R":0,"S":0,"D":0,"Z":0,"T":0,"t":0,"X":0,"I":0}
    files = glob("/proc/[0-9]*/stat")
    try:
        for file in files:
            with open(file, "r") as f:
                line = f.read()
                paren = line.find(") ")
                state = line[paren+2:paren+3]
                if state not in states:
                    states[state] = 0
                states[state] += 1
    except:
        pass
    
    print(datetime.now().time().isoformat("seconds"), end=" ")
    with open("/proc/loadavg", "r") as f:
        line = f.read()
        print(line[0:line.rfind(" ")], end="")
    for state in sorted(states):
        print(f" | {state}: {states[state]: <5}", end="")
    print()

    sleep(1)

[ Voor 26% gewijzigd door DataGhost op 24-06-2019 02:21 ]

Acties:

0 Henk 'm!

enthernal

Ik heb enige tijd geleden dezelfde problematiek voor gehad met mijn off-site NAS, ongeveer om de ander halve week geen verbinding meer. Uiteindelijk bleek het daar een slechte connectie van een netwerk kabel op de switch die bij de NAS stond te zijn. Als ik je kernel log bekijk dan lijken dat allen netwerk gerelateerde errors te zijn.

Ik zou:
- netwerk kabels controleren
- proberen een scherm oid. aan de NAS te hangen zodat je de console kan zien
- Indien dat niet kan; laat de NAS via een cronjob om de 10 minuten een lijntje naar een file schrijven. Wanneer hij "crasht" laat je hem even door draaien, dan kan je achteraf zien of hij effectief blok zat of gewoon niet bereikbaar was.

maandag 24 juni 2019 09:18

Acties:

0 Henk 'm!

Lethalis

Altijd van buiten naar binnen werken. Dus zoals @enthernal al zegt, begin bij het controleren van het netwerk.

Hang daarna een scherm en toetsenbord aan de server.

Als hij weer onbereikbaar is, doet hij het dan nog wel met scherm en toetsenbord?

Mocht dat niet zo zijn en er dus echt een hardware probleem is, dan zul je 1 voor 1 componenten moeten vervangen of verwijderen om tot de oorzaak te komen.

WDC Green schijven werken idd niet erg lekker op Linux, maar echte vastlopers had ik er niet mee. De firmware flash zorgt ervoor dat de koppen niet zo vaak geparkeerd worden, wat wel veel qua performance uitmaakte.

Ik ging destijds van 30MB per seconde naar bijna 100MB per seconde.

Dus zinvol was dat wel. Diezelfde schijven zitten nog in een oude Synology van mij en doen het nog steeds

Wel heb ik minder goede ervaringen met SSD's op Linux. Dat kan puur pech van mijn kant zijn geweest, maar 3 overleden SSD's in 3 jaar is wel veel... (maar dan was het systeem wel helemaal gaar, startte niet meer op etc)

Maar goed. Eerst scherm en toetsenbord aansluiten de volgende keer.

[ Voor 3% gewijzigd door Lethalis op 24-06-2019 09:21 ]

Ask yourself if you are happy and then you cease to be.

maandag 24 juni 2019 09:47

Acties:

0 Henk 'm!

CyberJack

Ik heb een vergelijkbaar issue gehad en dat bleek ook het netwerk te liggen. Machine was niet bereikbaar, maar draaide verder gewoon prima (met scherm en toetsenbord). Ik had de aansluiting op de muur (waar de netwerk kabel in moest) niet goed in elkaar gezet, waardoor de verbinding soms weg viel. Uiteindelijk een tang gekocht waarmee ik de kabeltjes goed kon vastzetten en daarna was het probleem voor mij op gelost.

Dus ik zou ook eerst kijken of de machine het wel doet met een scherm en toetsenbord.

Lethalis schreef op maandag 24 juni 2019 @ 09:18:
Wel heb ik minder goede ervaringen met SSD's op Linux. Dat kan puur pech van mijn kant zijn geweest, maar 3 overleden SSD's in 3 jaar is wel veel... (maar dan was het systeem wel helemaal gaar, startte niet meer op etc)

Ik neem aan dat je wel TRIM aangezet had (via cron/timer of via de "discard" optie in de fstab)?

https://bottenberg.dev

maandag 24 juni 2019 10:05

Acties:

0 Henk 'm!

maandag 24 juni 2019 10:11

Topicstarter

DataGhost schreef op maandag 24 juni 2019 @ 00:18:
Ik denk persoonlijk ook aan een I/O issue maar dat kan lastig troubleshooten zijn als het zo lang duurt tussen fouten. Ook al is er niks met je schijven kan bijvoorbeeld je controller gaar zijn. Als je op een fysieke console iets als dit kan laten draaien (als root):
while true; do echo -n "$(date +%Y%m%d-%H:%M:%S) "; cat /proc/[0-9]*/status 2>/dev/null | grep -P "^State:\s+D" | wc -l; sleep 1; done
zie je elke seconde hoeveel processen in state D (disk sleep) zitten. Als het een I/O-issue is zal je hoogstwaarschijnlijk hoge getallen gaan zien op het moment dat het misgaat. Normaal zal het een getal onder de vijf zijn ofzo, maar dat ligt helemaal aan wat je systeem allemaal doet. Ook als de machine veel met I/O bezig is zal dat nummer omhoog gaan. Als je echt I/O problemen hebt zullen veel processen in die state blijven hangen en gaat het hoge nummer dus niet meer omlaag.

In de tussentijd kan je ook kijken of je iets in je syslog (niet alleen kernel log) kan vinden rond die tijd, misschien zie je wel steeds hetzelfde proces wat logregels wegschrijft rond de tijd dat het misgaat. Daadwerkelijke logmessages van het moment zelf zul je waarschijnlijk niet tegenkomen, afhankelijk van wat het probleem is en hoe de machine hangt.

Edit2: heb je een swapfile/partitie, en hoe vol zit je geheugen doorgaans?

Edit: Ik had tijd over, je kan in plaats van dat commando hierboven ook dit script gebruiken voor misschien wat meer inzicht
Python:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#!/usr/bin/env python3
from glob import glob
from datetime import datetime
from time import sleep

while True:
    states = {"R":0,"S":0,"D":0,"Z":0,"T":0,"t":0,"X":0,"I":0}
    files = glob("/proc/[0-9]*/stat")
    try:
        for file in files:
            with open(file, "r") as f:
                line = f.read()
                paren = line.find(") ")
                state = line[paren+2:paren+3]
                if state not in states:
                    states[state] = 0
                states[state] += 1
    except:
        pass
    
    print(datetime.now().time().isoformat("seconds"), end=" ")
    with open("/proc/loadavg", "r") as f:
        line = f.read()
        print(line[0:line.rfind(" ")], end="")
    for state in sorted(states):
        print(f" | {state}: {states[state]: <5}", end="")
    print()

    sleep(1)

Thanks voor de moeite! Ik ben vandaag pas laat thuis maar ik ga dit morgenavond even proberen, dan kan ik ook gelijk het syslog checken. Ik vind het echt fantastisch dat je de tijd hebt genomen om hier een script voor te bouwen $_/-\o_$

Ik heb ook een logger op mijn geheugengebruik lopen en die komt niet boven de 65% doorgaans. HD gebruik komt niet boven de 50%. Swapfile heb ik niet ingesteld.

@enthernal @Lethalis @CyberJack Ook bedankt voor de tips over de netwerkkabels. Mijn router staat bovenop de NAS dus een andere netwerkkabel ertussen zou ook niet zoveel werk moeten zijn, ga ik ook proberen! Ik zal iig zorgen dat ik bij de volgende crash een toetsenbord + scherm eraan hang om het netwerk uit te sluiten. En de cronjob om de 10 minuten is ook een goed idee.

Bedankt allemaal voor wat nieuwe ideeën, ik hoop dat ik zo een diagnose kan stellen.

Stel dat het niet aan het netwerk ligt, wat zouden jullie dan aanraden om eerst te vervangen? Is natuurlijk een lastige vraag..

[ Voor 9% gewijzigd door Jlo88 op 24-06-2019 10:10 ]

Acties:

0 Henk 'm!

maandag 24 juni 2019 10:46

iPL dev

Jlo88 schreef op maandag 24 juni 2019 @ 10:05:
[...]

Thanks voor de moeite! Ik ben vandaag pas laat thuis maar ik ga dit morgenavond even proberen, dan kan ik ook gelijk het syslog checken. Ik vind het echt fantastisch dat je de tijd hebt genomen om hier een script voor te bouwen $_/-\o_$

Nja, het kan in andere situaties ook nuttig zijn voor mezelf

Ik heb dit soort dingen (I/O) al heel vaak moeten troubleshooten en elke keer schreef ik weer dezelfde oneliners.

Ik heb ook een logger op mijn geheugengebruik lopen en die komt niet boven de 65% doorgaans. HD gebruik komt niet boven de 50%. Swapfile heb ik niet ingesteld.

De kans is aanwezig dat er iets gebeurt waardoor je geheugengebruik piekt. Als het geheugen vol is kiest je kernel een proces om te killen. Dat zou bijvoorbeeld je SSH-server kunnen zijn (hoewel die kans klein is, maar wel aanwezig). Als je een swapfile/partitie hebt is er in ieder geval wat extra ruimte om mee te spelen. Je machine zal daar alleen maar vertraging van ondervinden als het geheugen daadwerkelijk een keer volraakt, anders niet, dus in de praktijk is het geen performance-penalty terwijl je wel beperkt dat een random service opeens niet meer draait.
Dit is de situatie op mijn server:

MiB Mem :  23038.9 total,  15928.3 free,   6619.1 used,    491.5 buff/cache
MiB Swap:   7808.0 total,   7808.0 free,      0.0 used.  16167.1 avail Mem

zolang het hoofdgeheugen niet volraakt wordt swap gewoon niet gebruikt.

Acties:

0 Henk 'm!

Brahiewahiewa

boelkloedig

Jlo88 schreef op zondag 23 juni 2019 @ 19:43:
[...]

Ik heb net even de SMART waarden bekeken, ik zie eigenlijk alleen iets geks bij de SSD die een uncorrectable-ecc-count van 5845 heeft...

Dat zou kunnen betekenen dat de SSD aan het overlijden is.

Otoh kun je ook FF checken of de TRIM support z'n werk wel doet

QnJhaGlld2FoaWV3YQ==

dinsdag 25 juni 2019 13:34

Acties:

0 Henk 'm!

dinsdag 25 juni 2019 16:52

Topicstarter

DataGhost schreef op maandag 24 juni 2019 @ 10:11:
[...]

Nja, het kan in andere situaties ook nuttig zijn voor mezelf Ik heb dit soort dingen (I/O) al heel vaak moeten troubleshooten en elke keer schreef ik weer dezelfde oneliners.

[...]

De kans is aanwezig dat er iets gebeurt waardoor je geheugengebruik piekt. Als het geheugen vol is kiest je kernel een proces om te killen. Dat zou bijvoorbeeld je SSH-server kunnen zijn (hoewel die kans klein is, maar wel aanwezig). Als je een swapfile/partitie hebt is er in ieder geval wat extra ruimte om mee te spelen. Je machine zal daar alleen maar vertraging van ondervinden als het geheugen daadwerkelijk een keer volraakt, anders niet, dus in de praktijk is het geen performance-penalty terwijl je wel beperkt dat een random service opeens niet meer draait.
Dit is de situatie op mijn server:
MiB Mem :  23038.9 total,  15928.3 free,   6619.1 used,    491.5 buff/cache
MiB Swap:   7808.0 total,   7808.0 free,      0.0 used.  16167.1 avail Mem 
zolang het hoofdgeheugen niet volraakt wordt swap gewoon niet gebruikt.

Ik heb nog even gekeken en als ik het script run is het hoogste wat ik voorbij zie komen een 1. Ik heb ook de swap nog gecheckt en die had ik dus wel al aanstaan

Ik heb 1g swap ingesteld. Zou dat voldoende zijn? Ik heb niet heel veel intern geheugen, maar aan de andere kant is het enige wat veel geheugen kan gebruiken iets uitpakken met sabnzbd oid. Misschien kan ik eens kijken of ik dat kan forceren met een grote download oid.

Swap file instellingen:

code:

1 2	NAME TYPE SIZE USED PRIO /swapfile file 1024M 262M -2

Huidige gebruik:

code:

1
2
3

              total        used        free      shared  buff/cache   available
Mem:           3620        1866         141          44        1612        1456
Swap:          1023         262         761

Ik heb ook nog de syslog doorgespit en daar zie ik rond de vermoedelijke crashtijd:

code:

Mar 18 02:05:23 Server systemd[1]: Started Run anacron jobs.
Mar 18 02:05:23 Server anacron[25013]: Anacron 2.3 started on 2019-03-18
Mar 18 02:05:23 Server anacron[25013]: Normal exit (0 jobs run)
Mar 18 02:08:00 Server kernel: [19443.940252] perf: interrupt took too long (4975 > 4961), lowering kernel.perf_event_max_sample_rate to 40000
Mar 18 02:09:11 Server nmbd[1277]: [2019/03/18 02:09:11.045341,  0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response)

Wat wel interessant is, de logs in syslog lopen gewoon door! Dus misschien is de NAS toch niet helemaal gecrasht. Ik heb mijn syslog ook online gezet: syslog

Acties:

+1 Henk 'm!

dinsdag 25 juni 2019 22:57

iPL dev

Mja, eerste wat ik persoonlijk doe als een machine niet meer lijkt te reageren is er een scherm+tobo aan hangen en kijken wat er aan de hand is. Dan kan je eens gaan kijken of sshd nog draait, hoe het met je CPU en RAM gebruik staat, of je netwerkverbinding nog up is (ifconfig en ping www.ams-ix.net). Ik ging er dus ten onrechte vanuit dat je dat al gedaan had, dit maakt de situatie waarschijnlijk een heel stuk simpeler.

[ Voor 10% gewijzigd door DataGhost op 25-06-2019 16:53 ]

Acties:

0 Henk 'm!

ninjazx9r98

Zoals al gezegd is, scherm en toetsenbord eraan knopen want het systeem loopt gewoon door na het tijdstip waarop je het vermoeden van een crash hebt. Waarom heb je dat vermoeden eigenlijk? Staat weinig spannends in de log op dat tijdstip.
Verderop in de log komt veel meer " rotzooi" voorbij van de networkmanager maar ook dan lijkt het systeem op zich gewoon door te lopen.

code:

Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.2490] device changed (path: /sys/devices/pci0000:00/0000:00:1c.3/0000:02:00.0/net/enp2s0, iface: enp2s0)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3439] device changed (path: /sys/devices/virtual/net/docker0, iface: docker0)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3449] device changed (path: /sys/devices/virtual/net/hassio, iface: hassio)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3454] device changed (path: /sys/devices/virtual/net/lo, iface: lo)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3460] device changed (path: /sys/devices/virtual/net/veth466c760, iface: veth466c760)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3464] device changed (path: /sys/devices/virtual/net/veth424fd4e, iface: veth424fd4e)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3468] device changed (path: /sys/devices/virtual/net/veth07e4d42, iface: veth07e4d42)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3474] device changed (path: /sys/devices/virtual/net/veth4c4ac4c, iface: veth4c4ac4c)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3478] device changed (path: /sys/devices/virtual/net/veth4b9cb64, iface: veth4b9cb64)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3482] device changed (path: /sys/devices/virtual/net/veth49c71bf, iface: veth49c71bf)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3488] device changed (path: /sys/devices/virtual/net/vethcb1172b, iface: vethcb1172b)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3491] device changed (path: /sys/devices/virtual/net/veth7e123fd, iface: veth7e123fd)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3494] device changed (path: /sys/devices/virtual/net/veth78b1d97, iface: veth78b1d97)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.3503] device changed (path: /sys/devices/virtual/net/vethe11c330, iface: vethe11c330)
Mar 18 07:42:03 Server NetworkManager[739]: <info>  [1552891323.4377] device changed (path: /sys/devices/pci0000:00/0000:00:1c.3/0000:02:00.0/net/enp2s0, iface: enp2s0)

Je hudige Ubuntu versie is overigens zo goed als end of life, hoe sta je er voor met patches/updates?

woensdag 26 juni 2019 21:00

Acties:

0 Henk 'm!

woensdag 26 juni 2019 22:10

Topicstarter

@ninjazx9r98 dat was mijn vermoeden in maart omdat dat de enige grote sprong in tijd was die ik zag. Ik zal zorgen dat ik er een toetsenbord + scherm aanhang volgende keer en wat beter door de logs heen spit.

Ik kan nu iig in home assistant exact zien wanneer sensorwaarden niet meer geupdate worden zodat ik het exacte moment van de "crash" of wat het ook is vast kan stellen.

Goede opmerking van de updates, is hard nodig indd..

Acties:

0 Henk 'm!

ninjazx9r98

@Jlo88
Met die sprong in tijd bedoel je die tweeënhalve minuut? Die staan er meer in (regel 72 & 73 op pastebin bijv) maar echt spannend is dat niet. Ik zou om te beginnen de boel updaten (en denken aan een upgrade naar een hogere versie), ook kijken naar een bios update mocht die er zijn.
Als er een keyboard aanhangt en de boel lijkt te hangen, log lokaal in en controleer of: networking draait, samba draait, diverse logfiles enz.

woensdag 26 juni 2019 23:05

Acties:

0 Henk 'm!

zondag 30 juni 2019 11:00

Topicstarter

@ninjazx9r98
Ik had in eerste instantie naar het kernel log gekeken, Daar zit een spring in van ongeveer 4u, ik heb toen de boel gereboot 's ochtends omdat ik de NAS niet meer kon bereiken. Inderdaad in het syslog lijkt dit niet het geval te zijn. Ik ben nog een beetje nieuw met in welke log ik wat kan vinden dus vandaar dat dit me niet gelijk opviel, ik heb alweer veel geleerd hier

Ik heb net de boel geupgrade naar 19.04, de bios update heb ik een paar maanden geleden al gedaan naar de laatste versie.

Advies is duidelijk, toetsenbord + scherm eraan als het volgende keer gebeurt en dan verder kijken. Thanks voor je hulp!

Acties:

0 Henk 'm!

zondag 30 juni 2019 11:16

Topicstarter

Op dit moment kan ik de NAS weer niet bereiken. Ik heb nu wel wat tijd om dingen te proberen.

Wat ik tot nu toe heb geprobeerd:

inloggen via SSH -> connection refused
pingen vanaf een laptop naar de NAS -> Succes!
Scherm en toetsenbord eraan, geen beeld. Ik gebruik nu de dvi poort met een converter naar hdmi op de tv, ik heb geen ander scherm. Normaal werkt dit met deze NAS
Caps-lock en num-lock werkt niet
ctrl + alt + t werkt niet
ctrl + alt + f1 werkt niet
samba werkt niet (kan de netwerk drives niet meer benaderen)

Ik zit nog te denken om ctrl + alt + s + u + b te doen om te rebooten maar dan weet ik weer niet wat het probleem is. Hebben jullie nog tips of dingen die ik kan proberen?

[ Voor 4% gewijzigd door Jlo88 op 30-06-2019 11:01 ]

Acties:

Beste antwoord ✓
+1 Henk 'm!

zondag 30 juni 2019 11:39

iPL dev

setterm -blank 0
setterm -powersave off
setterm -store

Acties:

0 Henk 'm!

zondag 30 juni 2019 12:40

Topicstarter

Okay, ik heb niets meer voor elkaar gekregen dus de machine gereboot.

Ik ziet in mijn monitoring script dat de laatste entry om 2019-06-30 07:40:01 geschreven is.

syslog tot 5 minuten hiervoor:

code:

Jun 30 07:35:01 Server CRON[13749]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)
Jun 30 07:35:01 Server CRON[13750]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jun 30 07:35:23 Server hd-idle[680]: disk=sda command=scsi spunDown=false reads=619728 writes=9237158 idleTime=0 idleDuration=0 spindown=0001-01-01T00:00:00 spinup=2019-06-26T22:08:28 lastIO=2019-06-30T07:35:23
Jun 30 07:35:23 Server hd-idle[680]: disk=sdc command=scsi spunDown=true reads=19558 writes=1368 idleTime=1800 idleDuration=3076 spindown=2019-06-30T07:14:17 spinup=2019-06-30T06:44:06 lastIO=2019-06-30T06:44:06
Jun 30 07:35:23 Server hd-idle[680]: disk=sdb command=scsi spunDown=true reads=9131 writes=0 idleTime=1800 idleDuration=3076 spindown=2019-06-30T07:14:17 spinup=2019-06-30T06:44:06 lastIO=2019-06-30T06:44:06
Jun 30 07:35:34 Server smartd[645]: Device: /dev/sdb [SAT], is in STANDBY mode, suspending checks
Jun 30 07:35:39 Server smartd[645]: Device: /dev/sdc [SAT], is in STANDBY mode, suspending checks
Jun 30 07:36:01 Server CRON[13947]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jun 30 07:36:01 Server CRON[13948]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)
Jun 30 07:36:16 Server anacron[12869]: Job `cron.daily' started
Jun 30 07:36:16 Server anacron[14070]: Updated timestamp for job `cron.daily' to 2019-06-30
Jun 30 07:36:16 Server cracklib: no dictionary update necessary.
Jun 30 07:36:19 Server anacron[12869]: Job `cron.daily' terminated
Jun 30 07:36:19 Server anacron[12869]: Normal exit (1 job run)
Jun 30 07:36:19 Server systemd[1]: anacron.service: Succeeded.
Jun 30 07:37:01 Server CRON[14386]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)
Jun 30 07:37:01 Server CRON[14387]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jun 30 07:37:44 Server dockerd[1453]: time="2019-06-30T07:37:44.033162498+02:00" level=warning msg="failed to retrieve runc version: unknown output format: runc version spec: 1.0.1-dev\n"
Jun 30 07:37:56 Server systemd[1415]: run-docker-runtime\x2drunc-moby-7796410871bbda126b71a78b779642c31b4624fb9c4bcaff886d877e31ad04ca-runc.ocSRKk.mount: Succeeded.
Jun 30 07:37:56 Server systemd[1]: run-docker-runtime\x2drunc-moby-7796410871bbda126b71a78b779642c31b4624fb9c4bcaff886d877e31ad04ca-runc.ocSRKk.mount: Succeeded.
Jun 30 07:38:01 Server CRON[14655]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jun 30 07:38:01 Server CRON[14654]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)
Jun 30 07:38:24 Server hd-idle[680]: disk=sda command=scsi spunDown=false reads=671244 writes=9243161 idleTime=0 idleDuration=0 spindown=0001-01-01T00:00:00 spinup=2019-06-26T22:08:28 lastIO=2019-06-30T07:38:24
Jun 30 07:38:24 Server hd-idle[680]: disk=sdc command=scsi spunDown=true reads=19558 writes=1368 idleTime=1800 idleDuration=3258 spindown=2019-06-30T07:14:17 spinup=2019-06-30T06:44:06 lastIO=2019-06-30T06:44:06
Jun 30 07:38:24 Server hd-idle[680]: disk=sdb command=scsi spunDown=true reads=9131 writes=0 idleTime=1800 idleDuration=3258 spindown=2019-06-30T07:14:17 spinup=2019-06-30T06:44:06 lastIO=2019-06-30T06:44:06
Jun 30 07:38:36 Server nmbd[1452]: [2019/06/30 07:38:36.599002,  0] ../../source3/nmbd/nmbd_namequery.c:109(query_name_response)
Jun 30 07:38:36 Server nmbd[1452]:   query_name_response: Multiple (2) responses received for a query on subnet 192.168.0.16 for name WORKGROUP<1d>.
Jun 30 07:38:36 Server nmbd[1452]:   This response was from IP 192.168.0.14, reporting an IP address of 192.168.0.14.
Jun 30 07:39:01 Server CRON[14952]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)
Jun 30 07:39:01 Server CRON[14953]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jun 30 07:40:01 Server CRON[15156]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jun 30 07:40:01 Server CRON[15157]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)

@DataGhost Wanneer ik de commandos probeer uit te voeren in een terminal via ctrl + alt + t krijg ik

code:

1	terminal xterm-256color does not support --blank

Doe ik hier iets verkeerds? Ik heb wat gelezen over tty maar ik ben hier helemaal niet bekend mee..

Edit: Excuses, heb nog wat verder gelezen en heb de commandos nu ingesteld via tty. Dit lijkt wel te werken. Is het idee dan dat ik de machine of tty laat staan en dan een tail-f van de syslog uitvoer?

Acties:

0 Henk 'm!

Lethalis

Merk jij niet dat jouw harde schijven eens in de zoveel tijd aan / uit gaan?

Ik zou hd-idle even niet meer gebruiken om te zien of dat helpt. Sowieso is het voor externe schijven bedoeld, voor interne schijven kun je ook hdparm -s gebruiken.

Maar voor de test zou ik de schijven even laten draaien.

[ Voor 40% gewijzigd door Lethalis op 30-06-2019 12:46 ]

Ask yourself if you are happy and then you cease to be.

zondag 30 juni 2019 12:48

Acties:

0 Henk 'm!

zondag 30 juni 2019 13:10

iPL dev

Inderdaad hd-idle is een verdachte. De commando's die ik noemde moet je inderdaad invoeren op een kale terminal, geen fancy X-dingen. Dus ctrl-alt-f[123456]. Je kan tail -F syslog (hoofdletter F) doen maar waarschijnlijk loopt zoiets al op ctrl-alt-f12.

Acties:

0 Henk 'm!

zondag 30 juni 2019 13:32

Topicstarter

@Lethalis Ik heb hd-idle 2 weken geinstalleerd. Ik zal het voor nu disablen. hdparm kreeg ik niet werkend met de green schrijven. Zie bijvoorbeeld hier . Het was juist de bedoeling dat mijn sdb en sdc uit gaan omdat die meestal niets staan te doen.

ik heb tail -f syslog nu draaien op tty3. Maakt -f of -F nog veel uit? Ik zie iig de log voorbij komen.

Acties:

+1 Henk 'm!

zondag 30 juni 2019 16:12

iPL dev

Ik zeg niet voor niets hoofdletter F. Kijk gewoon even in de help van tail, dan zie je vanzelf waarom. Het heeft iets met rotation te maken in ieder geval.

Acties:

0 Henk 'm!

dinsdag 9 juli 2019 20:38

Topicstarter

@DataGhost Had ik ook even zelf op kunnen zoeken indd.

Handleiding:

code:

1
2
3

-F     same as --follow=name --retry
--retry
              keep trying to open a file if it is inaccessible

Got it

Acties:

0 Henk 'm!

dinsdag 9 juli 2019 20:51

Topicstarter

Het is weer zover, deze keer heb ik er een monitor aanhangen met de output van syslog:

Afbeeldingslocatie: https://i.ibb.co/8PwkLnX/12e94850-e58d-4710-8c6d-d6d723f7e640.jpg

Ik kon niets met het toetsenbord doen, zelfs geen caps-lock.

Tot mijn verbazing zag ik dat hd-idle nog steeds actief was

. Ik heb nu hd-idle uit systemctl verwijderd, blijkbaar was apt-get remove en apt-get purge niet voldoende. Zoeken vanuit de root folder door

code:

1 2	find . -type d -name 'hd-idle' find . -type f -name 'hd-idle'

levert niets meer op en in syslog komt er ook niets meer met hd-idle voorbij.

Ik merkte dat er bij het rebooten geen boot medium gevonden kon worden tot ik nog een keer rebootte.. Dat is wel verdacht..

Laatste regels voor de crash:

code:

Jul  9 17:45:25 Server systemd[1442]: run-docker-runtime\x2drunc-moby-d70e73e47824b7d9de926c21eb746a669ffc869f02bb0a32e8c8409151893dd3-runc.670X8u.mount: Succeeded.
Jul  9 17:45:25 Server systemd[1]: run-docker-runtime\x2drunc-moby-d70e73e47824b7d9de926c21eb746a669ffc869f02bb0a32e8c8409151893dd3-runc.670X8u.mount: Succeeded.
Jul  9 17:45:25 Server systemd[11984]: run-docker-runtime\x2drunc-moby-d70e73e47824b7d9de926c21eb746a669ffc869f02bb0a32e8c8409151893dd3-runc.670X8u.mount: Succeeded.
Jul  9 17:45:53 Server nmbd[1477]: [2019/07/09 17:45:53.511062,  0] ../../source3/nmbd/nmbd_namequery.c:109(query_name_response)
Jul  9 17:45:53 Server nmbd[1477]:   query_name_response: Multiple (2) responses received for a query on subnet 192.168.0.16 for name WORKGROUP<1d>.
Jul  9 17:45:53 Server nmbd[1477]:   This response was from IP 192.168.0.14, reporting an IP address of 192.168.0.14.
Jul  9 17:46:01 Server CRON[12220]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)
Jul  9 17:46:01 Server CRON[12221]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jul  9 17:47:01 Server CRON[12384]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)
Jul  9 17:47:01 Server CRON[12385]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jul  9 17:48:01 Server CRON[12566]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jul  9 17:48:01 Server CRON[12567]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)
Jul  9 17:48:08 Server hd-idle[790]: disk=sdb command=scsi spunDown=true reads=5566 writes=0 idleTime=1800 idleDuration=38732 spindown=2019-07-09T07:32:45 spinup=2019-07-09T06:56:33 lastIO=2019-07-09T07:02:35
Jul  9 17:48:08 Server hd-idle[790]: disk=sdc command=scsi spunDown=false reads=2154 writes=132 idleTime=1800 idleDuration=362 spindown=2019-07-09T15:05:15 spinup=2019-07-09T16:17:38 lastIO=2019-07-09T17:42:06
Jul  9 17:48:08 Server hd-idle[790]: disk=sda command=scsi spunDown=false reads=166531 writes=1066933 idleTime=0 idleDuration=0 spindown=0001-01-01T00:00:00 spinup=2019-07-09T06:56:33 lastIO=2019-07-09T17:48:08
Jul  9 17:49:01 Server CRON[12759]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)
Jul  9 17:49:01 Server CRON[12760]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jul  9 17:49:05 Server dockerd[1475]: time="2019-07-09T17:49:05.034027997+02:00" level=warning msg="failed to retrieve runc version: unknown output format: runc version spec: 1.0.1-dev\n"
Jul  9 17:50:01 Server CRON[13002]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jul  9 17:50:01 Server CRON[13003]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)
Jul  9 17:50:25 Server systemd[1]: run-docker-runtime\x2drunc-moby-d70e73e47824b7d9de926c21eb746a669ffc869f02bb0a32e8c8409151893dd3-runc.yR73Er.mount: Succeeded.
Jul  9 17:50:25 Server systemd[11984]: run-docker-runtime\x2drunc-moby-d70e73e47824b7d9de926c21eb746a669ffc869f02bb0a32e8c8409151893dd3-runc.yR73Er.mount: Succeeded.
Jul  9 17:50:25 Server systemd[1442]: run-docker-runtime\x2drunc-moby-d70e73e47824b7d9de926c21eb746a669ffc869f02bb0a32e8c8409151893dd3-runc.yR73Er.mount: Succeeded.
Jul  9 17:50:53 Server nmbd[1477]: [2019/07/09 17:50:53.756997,  0] ../../source3/nmbd/nmbd_namequery.c:109(query_name_response)
Jul  9 17:50:53 Server nmbd[1477]:   query_name_response: Multiple (2) responses received for a query on subnet 192.168.0.16 for name WORKGROUP<1d>.
Jul  9 17:50:53 Server nmbd[1477]:   This response was from IP 192.168.0.14, reporting an IP address of 192.168.0.14.
Jul  9 17:51:01 Server CRON[13187]: (root) CMD (/bin/bash /home/jan/Appdata/Crashlogs/timestampjob >> /home/jan/Appdata/Crashlogs/timestampjob.log 2>&1)
Jul  9 17:51:01 Server CRON[13186]: (root) CMD (/usr/bin/python /home/jan/Appdata/CollectSensorData/Collect-sensor-data.py)
Jul  9 17:51:09 Server hd-idle[790]: disk=sdb command=scsi spunDown=true reads=5566 writes=0 idleTime=1800 idleDuration=38913 spindown=2019-07-09T07:32:45 spinup=2019-07-09T06:56:33 lastIO=2019-07-09T07:02:35
Jul  9 17:51:09 Server hd-idle[790]: disk=sdc command=scsi spunDown=false reads=2154 writes=135 idleTime=1800 idleDuration=0 spindown=2019-07-09T15:05:15 spinup=2019-07-09T16:17:38 lastIO=2019-07-09T17:51:09
Jul  9 17:51:09 Server hd-idle[790]: disk=sda command=scsi spunDown=false reads=166533 writes=1071742 idleTime=0 idleDuration=0 spindown=0001-01-01T00:00:00 spinup=2019-07-09T06:56:33 lastIO=2019-07-09T17:51:09
                                                                                                                                                                                                                                                                                     Jul  9 20:07:31 Server kernel: [    0.000000] microcode: microcode updated early to revision 0x27, date = 2019-02-26

Acties:

+1 Henk 'm!

dinsdag 9 juli 2019 21:07

Moderator LNX

There is only one Legend

Die regels uit syslog laten eigenlijk niets zien. De foto van het scherm echter wel. Daar is te zien dat processen wat willen doen met je primaire schijf, maar dat niet meer kunnen. Ik denk dat sda2 je root schijf is. Dat is niet meer te benaderen, of iig data van op te halen. En dan gaat schrijven ook niet meer zo lekker. Had je de SMART waardes al opnieuw bekeken? Wat je hier eerder hebt gepost lijkt namelijk op old-age. Het heeft toen schijnbaar lang genoeg aangestaan om bijna 4 jaar non-stop te werken. Lijkt er toch op dat het tegen 't einde loopt. Ook je verdachte boot is een teken.

Commandline FTW | Tweakt met mate

Acties:

0 Henk 'm!

dinsdag 9 juli 2019 21:58

Topicstarter

@Hero of Time Ja klopt, sda2 is de root schijf.

Heb net de smart-waarden weer eens bekeken. Ik had begrepen dat alle waarden hoger dan de threshold moeten zijn behalve de temperatuur. Aangezien bij bijna alles de threshold 0 is lijkt dit prima toch? Of interpreteer ik het verkeerd?

code:

smartctl 6.6 2017-11-05 r4594 [x86_64-linux-5.0.0-20-generic] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     SandForce Driven SSDs
Device Model:     KINGSTON SV300S37A60G
Serial Number:    50026B774A05BBA1
LU WWN Device Id: 5 0026b7 74a05bba1
Firmware Version: 580ABBF0
User Capacity:    60,022,480,896 bytes [60,0 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS, ACS-2 T13/2015-D revision 3
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Jul  9 20:59:40 2019 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x02) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                (    0) seconds.
Offline data collection
capabilities:                    (0x7d) SMART execute Offline immediate.
                                        No Auto Offline data collection support.
                                        Abort Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   1) minutes.
Extended self-test routine
recommended polling time:        (  48) minutes.
Conveyance self-test routine
recommended polling time:        (   2) minutes.
SCT capabilities:              (0x0025) SCT Status supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x0032   095   095   050    Old_age   Always       -       2/17936863
  5 Retired_Block_Count     0x0033   100   100   003    Pre-fail  Always       -       0
  9 Power_On_Hours_and_Msec 0x0032   061   061   000    Old_age   Always       -       34956h+10m+49.310s
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       149
171 Program_Fail_Count      0x000a   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
174 Unexpect_Power_Loss_Ct  0x0030   000   000   000    Old_age   Offline      -       127
177 Wear_Range_Delta        0x0000   000   000   000    Old_age   Offline      -       96
181 Program_Fail_Count      0x000a   100   100   000    Old_age   Always       -       0
182 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
187 Reported_Uncorrect      0x0012   100   100   000    Old_age   Always       -       0
189 Airflow_Temperature_Cel 0x0000   038   042   000    Old_age   Offline      -       38 (Min/Max 13/42)
194 Temperature_Celsius     0x0022   038   042   000    Old_age   Always       -       38 (Min/Max 13/42)
195 ECC_Uncorr_Error_Count  0x001c   104   104   000    Old_age   Offline      -       2/17936863
196 Reallocated_Event_Count 0x0033   100   100   003    Pre-fail  Always       -       0
201 Unc_Soft_Read_Err_Rate  0x001c   104   104   000    Old_age   Offline      -       2/17936863
204 Soft_ECC_Correct_Rate   0x001c   104   104   000    Old_age   Offline      -       2/17936863
230 Life_Curve_Status       0x0013   100   100   000    Pre-fail  Always       -       100
231 SSD_Life_Left           0x0013   092   092   010    Pre-fail  Always       -       0
233 SandForce_Internal      0x0032   000   000   000    Old_age   Always       -       10488
234 SandForce_Internal      0x0032   000   000   000    Old_age   Always       -       6234
241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   Always       -       6234
242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   Always       -       5883

SMART Error Log not supported

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%     33221         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Begrijp me niet verkeerd, ik wil heel graag een nieuwe SSD kopen als dit het probleem is

Bedankt voor je hulp!

Acties:

0 Henk 'm!

dinsdag 9 juli 2019 22:04

Moderator LNX

There is only one Legend

Waarom heb je nu opeens andere waarden voor je schijf? Eerder postte je de smart status van je SSD en stond er dit:

234 uncorrectable-ecc-count     n/a   n/a     0   5845 sectors 0xd51600000000 old-age online  n/a  n/a

Nu is 234 iets heel anders en is bovenstaande ook niet meer terug te vinden.

Je hebt wel een Sandforce aangestuurde schijf. Ik vertrouw die controller niet zo, sinds de Vertex 2, al zal dat issue nu niet meer van toepassing zijn. Toch is de schijf al redelijk oud en heeft het lang aangestaan.

Commandline FTW | Tweakt met mate

Acties:

0 Henk 'm!

dinsdag 9 juli 2019 22:46

Topicstarter

Sorry voor de verwarring, ligt aan de manier van uitlezen, hier zijn de waarden met

code:

1	sudo skdump /dev/sda

smart waarden:

code:

[Device: sat16:/dev/sda
Type: 16 Byte SCSI ATA SAT Passthru
Size: 57241 MiB
Model: [KINGSTON SV300S37A60G]
Serial: [50026B774A05BBA1]
Firmware: [580ABBF0]
SMART Available: yes
Quirks:
Awake: yes
SMART Disk Health Good: yes
Off-line Data Collection Status: [Off-line data collection activity was completed without error.]
Total Time To Complete Off-Line Data Collection: 0 s
Self-Test Execution Status: [The previous self-test routine completed without error or no self-test has ever been run.]
Percent Self-Test Remaining: 0%
Conveyance Self-Test Available: yes
Short/Extended Self-Test Available: yes
Start Self-Test Available: yes
Abort Self-Test Available: yes
Short Self-Test Polling Time: 1 min
Extended Self-Test Polling Time: 48 min
Conveyance Self-Test Polling Time: 2 min
Bad Sectors: 0 sectors
Powered On: 4.0 years
Power Cycles: 149
Average Powered On Per Power Cycle: 9.8 days
Temperature: 37.0 C
Attribute Parsing Verification: Good
Overall Status: GOOD
ID# Name                        Value Worst Thres Pretty      Raw            Type    Updates Good Good/Past
  1 raw-read-error-rate          95    95    50   8608037205  0x553914010200 old-age online  yes  yes
  5 reallocated-sector-count    100   100     3   0 sectors   0x000000000000 prefail online  yes  yes
  9 power-on-hours               61    61     0   4.0 years   0x8d8800004049 old-age online  n/a  n/a
 12 power-cycle-count           100   100     0   149         0x950000000000 old-age online  n/a  n/a
171 program-fail-count          100   100     0   0           0x000000000000 old-age online  n/a  n/a
172 erase-fail-count            100   100     0   0           0x000000000000 old-age online  n/a  n/a
174 attribute-174               n/a   n/a     0   n/a         0x7f0000000000 old-age offline n/a  n/a
177 wear-leveling-count         n/a   n/a     0   96          0x600000000000 old-age offline n/a  n/a
181 program-fail-count-total    100   100     0   0           0x000000000000 old-age online  n/a  n/a
182 erase-fail-count-total      100   100     0   0           0x000000000000 old-age online  n/a  n/a
187 reported-uncorrect          100   100     0   0 sectors   0x000000000000 old-age online  n/a  n/a
189 high-fly-writes              37    42     0   55837327397 0x25002a000d00 old-age offline n/a  n/a
194 temperature-celsius-2        37    42     0   37.0 C      0x25002a000d00 old-age online  n/a  n/a
195 hardware-ecc-recovered      104   104     0   8608037205  0x553914010200 old-age offline n/a  n/a
196 reallocated-event-count     100   100     3   0           0x000000000000 prefail online  yes  yes
201 soft-read-error-rate        104   104     0   8608037205  0x553914010200 old-age offline n/a  n/a
204 shock-count-write-open      104   104     0   8608037205  0x553914010200 old-age offline n/a  n/a
230 head-amplitude              100   100     0   n/a         0x640000000000 prefail online  n/a  n/a
231 temperature-celsius          92    92    10   0.0 C       0x000000000000 prefail online  yes  yes
233 power-on-seconds-2          n/a   n/a     0   n/a         0xf92800000000 old-age online  n/a  n/a
234 uncorrectable-ecc-count     n/a   n/a     0   6235 sectors 0x5b1800000000 old-age online  n/a  n/a
241 total-lbas-written          n/a   n/a     0   209.211 GB  0x5b1800000000 old-age online  n/a  n/a
242 total-lbas-read             n/a   n/a     0   197.400 GB  0xfb1600000000 old-age online  n/a  n/a

Vorige resultaten waren uitgelezen met

code:

1	sudo smartctl --all /dev/sda

. Ik had niet verwacht dat dit andere resultaten zou geven.

Ik ben alvast voor een nieuwe SSD aan het kijken, ik zie deze bijvoorbeeld. Zijn er nog dingen waar ik op kan letten om dit te voorkomen? Is een SSD sowieso wel een goed idee voor een NAS? Mijn gedachtengang was energieverbruik en snelheid..

[ Voor 4% gewijzigd door Jlo88 op 09-07-2019 22:12 . Reden: Nieuwe SSD keuze toegevoegd ]

Acties:

0 Henk 'm!

dinsdag 9 juli 2019 23:55

Moderator LNX

There is only one Legend

Ik krijg met mijn Crucial schijf dezelfde data terug, maar bij jou is met skdump iig duidelijker zichtbaar dat je schijf rot wordt/is. Als je echt een SSD als vervanger wilt, zou ik persoonlijk een paar dubbeltjes meer neerleggen voor een pricewatch: Crucial BX500 120GB. Heeft duidelijk een andere controller (de Kingston die je linkt heeft geen controller vermeld in de specs hier) en heeft een mtbf van een half miljoen uur meer.

Commandline FTW | Tweakt met mate

Acties:

0 Henk 'm!

Brahiewahiewa

boelkloedig

Hero of Time schreef op dinsdag 9 juli 2019 @ 22:46:
... een pricewatch: Crucial BX500 120GB. Heeft duidelijk een andere controller (de Kingston die je linkt heeft geen controller vermeld in de specs hier) en heeft een mtbf van een half miljoen uur meer.

Hmmz, denk toch niet dat Crucial een garantie voor 500000 uur gaat geven ;o)

QnJhaGlld2FoaWV3YQ==

dinsdag 9 juli 2019 23:59

Acties:

0 Henk 'm!

woensdag 10 juli 2019 06:45

Moderator LNX

There is only one Legend

Brahiewahiewa schreef op dinsdag 9 juli 2019 @ 23:55:
[...]

Hmmz, denk toch niet dat Crucial een garantie voor 500000 uur gaat geven ;o)

Het is zoveel meer dan de Kingston. Het is een teken van betrouwbaarheid. Je kan altijd een rotte appel hebben, maar een verwachte levensduur dat 50% hoger ligt dan een ander vergelijkbaar ander product is toch best aanzienlijk.

Commandline FTW | Tweakt met mate

Acties:

0 Henk 'm!

dinsdag 16 juli 2019 22:26

Topicstarter

@Hero of Time, mee eens. Dan ga ik die vandaag bestellen en dan dit weekend een verse install op mijn NAS zetten. Ik hoop dat dit het oplost!

Acties:

0 Henk 'm!