12.3 + Amanda -> und ewig hängt das Murmeltier

while : ; do date >> counter.txt ; sleep 10 ; done

Öhmm ... ich merke, ich bin noch weniger fit in sh scripten als früher ...

Code:
# while : ; do date >> counter.txt ; sleep 10 ; done
while: Expression Syntax.
do: Command not found.
done: Command not found.

Es macht doch vermutlich auch eher Sinn, das ganze als cron job kurz vor dem amanda cron job zu starten oder?
 
Öhmm ... ich merke, ich bin noch weniger fit in sh scripten als früher ...

Code:
# while : ; do date >> counter.txt ; sleep 10 ; done
while: Expression Syntax.
do: Command not found.
done: Command not found.

Es macht doch vermutlich auch eher Sinn, das ganze als cron job kurz vor dem amanda cron job zu starten oder?
Ich glaube du hast da eine csh, brauchst aber eine sh... Aber egal. Per Cronjob kurz vor dem Backup zu starten, geht natürlich auch. Dafür nochmal als komplettes Script. Das kann dann in eine Datei, die ausführbar gemacht vercront werden:

Code:
#!/bin/sh

while : ; do
    date >> /root/counter.txt
    sleep 10
done
 
Das war ein kurzes Vergnügen ...

Code:
# tail counter.txt
Thu Apr 21 02:25:49 CEST 2022
Thu Apr 21 02:25:59 CEST 2022
Thu Apr 21 02:26:09 CEST 2022
Thu Apr 21 02:26:19 CEST 2022
Thu Apr 21 02:26:29 CEST 2022
Thu Apr 21 02:26:39 CEST 2022
Thu Apr 21 02:26:49 CEST 2022
Thu Apr 21 02:26:59 CEST 2022
Thu Apr 21 02:27:09 CEST 2022
Thu Apr 21 02:27:19 CEST 2022

Code:
% amstatus HS24Backup
Using /var/db/amanda/state/log/amdump
From Thu Apr 21 01:15:00 CEST 2022

sql.hobbyschneiderin24.net:/         0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
sql.hobbyschneiderin24.net:/usr      0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
sql.hobbyschneiderin24.net:/usr/home 0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
sql.hobbyschneiderin24.net:/var      0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
sql.hobbyschneiderin24.net:/var/log  0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
sql.hobbyschneiderin24.net:/var/mail 0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
www.hobbyschneiderin24.net:/         0  96747570k failed: process terminated while waiting for dumping
www.hobbyschneiderin24.net:/usr      0  88230090k failed: killed while dumping to tape (45616640k done (51.70%)) (2:16:24)
www.hobbyschneiderin24.net:/usr/home 0        20k finished (2:15:14)
www.hobbyschneiderin24.net:/var      0   1886530k finished (2:16:24)
www.hobbyschneiderin24.net:/var/log  0    134370k finished (2:15:44)
www.hobbyschneiderin24.net:/var/mail 0     25850k finished (2:15:28)

SUMMARY          part      real  estimated
                           size       size
partition       :  12
estimated       :   9            784339462k
flush           :   0         0k
failed          :   6            597316860k           ( 76.16%)
wait for dumping:   1             96747570k           ( 12.33%)
dumping to tape :   1  45616640k  88230090k ( 51.70%) ( 11.25%)
dumping         :   0         0k         0k (  0.00%) (  0.00%)
dumped          :   4   2046770k   2044942k (100.09%) (  0.26%)
wait for writing:   0         0k         0k (  0.00%) (  0.00%)
wait to flush   :   0         0k         0k (100.00%) (  0.00%)
writing to tape :   0         0k         0k (  0.00%) (  0.00%)
failed to tape  :   0         0k         0k (  0.00%) (  0.00%)
taped           :   4   2046770k   2044942k (100.09%) (  0.26%)
  tape 1        :   4   2046770k   2046770k (  0.49%) HS24Backup01 (4 chunks)
9 dumpers idle  : 0
taper 0 status: Writing www.hobbyschneiderin24.net:/usr
taper qlen: 0
network free kps:     78976
holding space   :         0k (  0.00%)
 dumper0 busy   :  0:01:22  (  2.24%)
   taper busy   :  0:01:22  (  2.23%)
 0 dumpers busy :  1:00:06  ( 97.84%)                   0:  1:00:06  (100.00%)
 1 dumper busy  :  0:01:19  (  2.16%)                   0:  0:01:19  (100.00%)

Unabhängig von den Problemen mit dem sql-server der seine Daten nicht liefert, scheint mir der hier interessant zu sein:
www.hobbyschneiderin24.net:/usr 0 88230090k failed: killed while dumping to tape (45616640k done (51.70%)) (2:16:24)

Und der Counter ist um 2:27 weggestorben.

Die letzten Bots aus auth.log:

Code:
Apr 21 02:23:47 mcp sshd[17508]: Disconnected from invalid user cirros 77.27.144.144 port 37293 [preauth]
Apr 21 02:25:58 mcp sshd[17538]: reverse mapping checking getaddrinfo for hn.kd.ny.adsl [123.7.38.3] failed.
Apr 21 02:25:58 mcp sshd[17538]: Bad protocol version identification '-HSS2.0-libssh2_1.4.3' from 123.7.38.3 port 48584
Apr 21 13:33:46 mcp sshd[2274]: Server listening on :: port 22.
Apr 21 13:33:46 mcp sshd[2274]: Server listening on 0.0.0.0 port 22.

cron stirbt auch um die Zeit.

Der Server hängt vollständig und braucht einen Tritt.
 
Ich hatte neulich nen fehler da ist meist beim rsync die Kiste verstorben - letztlich wars evtl. nen wackeliges SATA-Kabel oder nen nicht so toller contoller - ich hatte beides dann Zeitgleich aufgrund des tipps vom @mr44er gewechselt.

Gibt es noch andere Szenarien bei dem ähnlich die Hardware gefordert wird?
 
Interessant ist, dass die Box einfach einfriert. Bei einer Panic wird eigentlich nach etwa 30 Sekunden automatisch rebootet. Man könnte versuchen Crashdumps einzuschalten, aber bringen wird es eher nichts, weil er eher keinen Dump schreibt: dumpdev=AUTO in die rc.conf, anschließend wird in die ersten Swap-Partition ein Dump geschrieben und nach dem Reboot in /var/crash gesichert.

So wirklich Optionen etwas aus der Ferne zu erreichen, sehe ich aber leider auch nicht. @CommanderZed hat einen guten Ansatz. Schrittweise durchanalysieren. Gibt es andere Lastszenarien, die überleben? Kann man z.B. durch einen Dateisystembenchmark den Crash reproduzieren?
 
In post#23 hast du 88161570k failed: killed while dumping to tape (29513088k done (33.48%)) (1:20:06)

Da die Kiste 32G RAM und 12.3 hat, hätte ich drauf getippt, dass man den ARC mal beschränkt. Vergiss das, hast du ja schon. :o
/boot/loader.conf
->
vfs.zfs.arc_max="8G" oder 16 und dann erstmal rebooten.

Dagegen spricht #31 mit 88230090k failed: killed while dumping to tape (45616640k done (51.70%)) (2:16:24)
Dafür spricht, dass es in beiden Fällen beim größten Klopper /usr passiert.

Ich würde den ARC beschränken, die HW-Beschleunigung deaktivieren (sind beides keine schlechten 'Bastelsettings', im Gegenteil) und mich dann erneut auf die Lauer legen.
Edit: der nächste Schritt mit dem crashdump sollte auch Klarheit verschaffen.
 
Ich hatte neulich nen fehler da ist meist beim rsync die Kiste verstorben - letztlich wars evtl. nen wackeliges SATA-Kabel oder nen nicht so toller contoller - ich hatte beides dann Zeitgleich aufgrund des tipps vom @mr44er gewechselt.

Gibt es noch andere Szenarien bei dem ähnlich die Hardware gefordert wird?
Ich fress' nen Besen, das Board hat auch einen Marvell und einen Intel-SATA-Chip. :ugly:
'Leider' (weil das sonst das Problem wäre) hängen die Platten aber alle am Intel, wenn ich das richtig sehe.

@peterle: Du könntest den Marvell-chip im BIOS ausschalten, sicher ist sicher.
 
Gibt es noch andere Szenarien bei dem ähnlich die Hardware gefordert wird?

Nein, allenfalls Daten aus dem Seafile "wild hin- und herkopieren", aber daraus kann ich zumindest mal testen, was passiert, wenn er nur lokal eine ähnlich große Menge an Daten sichert, dann ist zumindest die Netzwerkkarte draußen.
 
dumpdev=AUTO in die rc.conf, anschließend wird in die ersten Swap-Partition ein Dump geschrieben und nach dem Reboot in /var/crash gesichert.

Da guck - das hatte ich sowieso in der /etc/rc.conf drinstehen:
Code:
# grep dumpdev /etc/rc.conf
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"

# sysctl kern.coredump
kern.coredump: 1

Hat aber nichts genutzt, weil /var/crash nur eine Datei namens minfree hat und die ist von 2018
 
Steht die Kiste nicht bei Hetzner? Könnte schwierig werden :-)

PS: ich finde den Thread, auch ohne betroffen zu sein, sehr interessant
Ich habe mal viel Splinter Cell gespielt ... :p

Ok, Spaß beiseite -
Hardwarebeschleunigung ausgeschaltet mit ifconfig re0 -rxcsum -txcsum und der arc steht jetzt auf 8GB und dann lasse ich den counter wieder laufen.

Als nächstes soll Hetzner sich mal die Hardware anschauen. Die sind erschreckend oft mittlerweile "mau".
 
Bei Hetzner kann man eine Lara Konsole zeitlich begrenzt bekommen. Das ist als ob man vor der Küste steht. Geht über den Support. ;)
 
Da kommt man auch ins BIOS.

Aaaaaah! Was mach ich da?

Bonnie ist übrigens einmal durchgelaufen:

Code:
# bonnie -m mcp -s 130000
File './Bonnie.2396', size: 136314880000
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
mcp      130000 491244 99.0 1351027 96.5 922422 98.1 480427 100.0 2454035 100.0 43667.2 271.5
 
Die Lara Konsole ist ein externes Gerät das Tastatur, Maus und VGA per Netzwerk an dich weiter leitet. Damit kann man auch ein ISO mounten und davon installieren. ;)

Damit konnte ich alle Probleme finden.
 
Und noch ein Durchlauf ohne irgendwelche Probleme:

Code:
# bonnie -m mcp -s 390000
File './Bonnie.2463', size: 408944640000
Writing with putc()...done
Rewriting...done
Writing intelligently...done
Reading with getc()...done
Reading intelligently...done
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
mcp      390000 492140 99.0 1336503 95.7 656273 73.6 464541 99.1 2064415 97.1 446.8  2.7
 
Nächste Runde ...

Code:
# tail counter1.txt
Fri Apr 22 02:21:59 CEST 2022
Fri Apr 22 02:22:09 CEST 2022
Fri Apr 22 02:22:20 CEST 2022
Fri Apr 22 02:22:30 CEST 2022
Fri Apr 22 02:22:40 CEST 2022
Fri Apr 22 02:22:50 CEST 2022
Fri Apr 22 02:23:00 CEST 2022
Fri Apr 22 02:23:11 CEST 2022
Fri Apr 22 02:23:21 CEST 2022
Fri Apr 22 02:23:31 CEST 2022


# tail -15 /var/log/auth.log
Apr 22 02:23:01 mcp sshd[8105]: Disconnected from authenticating user root 124.221.128.250 port 35122 [preauth]
Apr 22 02:23:25 mcp sshd[8113]: Received disconnect from 124.221.128.250 port 38218:11: Bye Bye [preauth]
Apr 22 02:23:25 mcp sshd[8113]: Disconnected from authenticating user root 124.221.128.250 port 38218 [preauth]
Apr 22 09:26:16 mcp sshd[2257]: Server listening on :: port 22.



% amstatus HS24Backup
Using /var/db/amanda/state/log/amdump
From Fri Apr 22 01:15:01 CEST 2022

sql.hobbyschneiderin24.net:/         0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
sql.hobbyschneiderin24.net:/usr      0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
sql.hobbyschneiderin24.net:/usr/home 0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
sql.hobbyschneiderin24.net:/var      0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
sql.hobbyschneiderin24.net:/var/log  0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
sql.hobbyschneiderin24.net:/var/mail 0 failed: planner: [Some estimate timeout on sql.hobbyschneiderin24.net]
www.hobbyschneiderin24.net:/         0  96758270k failed: process terminated while waiting for dumping
www.hobbyschneiderin24.net:/usr      0  88236480k failed: killed while dumping to tape (29166176k done (33.05%)) (2:16:25)
www.hobbyschneiderin24.net:/usr/home 0        20k finished (2:15:16)
www.hobbyschneiderin24.net:/var      0   1886510k finished (2:16:25)
www.hobbyschneiderin24.net:/var/log  0    136230k finished (2:15:45)
www.hobbyschneiderin24.net:/var/mail 0     25850k finished (2:15:29)

SUMMARY          part      real  estimated
                           size       size
partition       :  12
estimated       :   9            790293272k
flush           :   0         0k
failed          :   6            603252500k           ( 76.33%)
wait for dumping:   1             96758270k           ( 12.24%)
dumping to tape :   1  29166176k  88236480k ( 33.05%) ( 11.17%)
dumping         :   0         0k         0k (  0.00%) (  0.00%)
dumped          :   4   2048610k   2046022k (100.13%) (  0.26%)
wait for writing:   0         0k         0k (  0.00%) (  0.00%)
wait to flush   :   0         0k         0k (100.00%) (  0.00%)
writing to tape :   0         0k         0k (  0.00%) (  0.00%)
failed to tape  :   0         0k         0k (  0.00%) (  0.00%)
taped           :   4   2048610k   2046022k (100.13%) (  0.26%)
  tape 1        :   4   2048610k   2048610k (  0.49%) HS24Backup02 (4 chunks)
9 dumpers idle  : 0
taper 0 status: Writing www.hobbyschneiderin24.net:/usr
taper qlen: 0
network free kps:     78976
holding space   :         0k (  0.00%)
 dumper0 busy   :  0:01:21  (  2.22%)
   taper busy   :  0:01:21  (  2.20%)
 0 dumpers busy :  1:00:06  ( 97.86%)                   0:  1:00:06  (100.00%)
 1 dumper busy  :  0:01:18  (  2.14%)                   0:  0:01:18  (100.00%)

Selbe Zeit, selbes Spiel:
www.hobbyschneiderin24.net:/usr 0 88236480k failed: killed while dumping to tape (29166176k done (33.05%)) (2:16:25)

:o :confused:
 
Zuletzt bearbeitet:
Die selbe Uhrzeit bei unterschiedlichen Fortschritten spricht zumindest etwas gegen die disks.
Allerdings starten um 3:15 die periodic-scripts. Stimmt denn die Uhrzeit?
 
Zurück
Oben