Ubuntu 8.04 - scp stalled

[_reboot_]

Op het werk hebben wij een probleem met het kopieren van bestanden met onze Ubuntu 8.04 machines over het internet m.b.v. scp en rsnapshot. Beide servers staan in hetzelfde LAN. De backup machine maakt m.b.v. rsnapshot backups van de development server. Dit werkt en geeft/heeft geen problemen.

Om de backups goed veilig te stellen maken we niet alleen op de lokale backup machine backups van de development server, maar doen we dit ook nog via de internetverbinding naar onze Backup machine in Amsterdam. Dit is ook een Ubuntu machine die wij gedeeltelijk zelf kunnen beheren. Deze backup machine maakt (normaal gesproken) iedere nacht een backup m.b.v. rsnapshot van onze development server.

Alles heeft in principe altijd goed gedraaid. Totdat wij naar ons nieuwe kantoor gingen. Sinds die tijd functioneert het niet meer. Op onze oude locatie hadden wij een ADSL verbinding van XS4ALL. De router was een SpeedTouch 780. Switches waren standaard huis tuin en keuken merken. Hier functioneerde alles altijd perfect. Sinds wij op onze nieuwe locatie zitten hebben wij een fiber aansluiting van @Work. Als router hebben wij nu een Zyxell ZyWall 5 die m.b.v. NAT poort 22 forward naar de development server en deze tevens firewalled op basis van IP. Wij kunnen van onze backup server in Amsterdam met ssh verbinden op de development server op kantoor, dus hier lijkt in eerste instantie ook alles in orde. Tevens hebben we een nieuwe switch geinstalleerd i.p.v. 3 huis, tuin en keuken switches. De switch die er momenteel staat is een '3Com baseline 2924 Plus'.

Het probleem treedt op wanneer we iets willen kopieren. Ik kan van de development server naar de lokale backup machine kopieren m.b.v. scp. Dezelfde set bestanden de andere kant op gaat ook goed. Maar wanneer ik nu data via rsnapshot wil laten backuppen van de backup server in Amsterdam dan kan ik hem een week laten draaien zonder dat hij verder komt. Wanneer ik vanaf de backup server in Amsterdam m.b.v. scp een kopie wil maken van de data van de development server, dan stalled hij na een paar bestanden al. En het lijkt op te vallen dat hij problemen heeft met grotere bestanden. Bijvoorbeeld de MySQL dumps, daar stalled hij mee bij bestanden van 1,5 MB. Maar ook van bestanden van 6 MB. Een exacte grootte kan ik op dit moment nog niet geven. Maar bestanden van 300kb gaan prima. Dus het lijkt ergens te liggen tussen de 300kb en de 1,5 MB. Ditzelfde effect heb ik ook wanneer ik data wil kopieren vanaf de backup machine in Amsterdam van onze backup server.

Voor de duidelijkheid: in beide scenario's ben ik ingelogd op de backup machine in Amsterdam en voer ik het scp commando uit om data te kopieren van de development of backup machine van ons kantoor naar de backup machine in Amsterdam.

Hieronder heb ik de specificaties van de 3 betreffende server. Zoals is te zien zijn alle 3 de Ubuntu kernels gelijk. Het enige directe verschil is de backup01 in Amsterdam. Deze is 64 bit. De backup machine in Amsterdam maakt tevens met rsnapshot backups van onze webserver en database server. Dit draait prima. En lijken mij verder niet noemenswaardig in dit scenario.

Backup server @ True (backup01):
Ubuntu 8.04,
Kernel: Linux backup01.<knip> 2.6.24-19-server #1 SMP Fri Jul 11 21:50:43 UTC 2008 x86_64

Development server (webdev):
Ubuntu 8.04,
Kernel: Linux webdev 2.6.24-19-server #1 SMP Wed Aug 20 23:54:28 UTC 2008 i686

Backup server (backup):
Ubuntu 8.04,
Kernel: Linux backup 2.6.24-19-server #1 SMP Wed Aug 20 23:54:28 UTC 2008 i686

Wat heb ik al geprobeerd. Tsja. Behalve dat we zo langzamerhand vaste klant zijn van Google en menig Ubuntu forum, hebben we inmiddels uitgesloten dat het de router en de nieuwe switch kunnen zijn.We hebben namelijk de development server rechtstreeks op de ethernet kabel aangesloten van @Work. Ook dan hebben wij hetzelfde probleem met kopieren. Daarnaast hebben we getest of een andere MTU waarde nog invloed zou hebben. We hebben 1490 getest, maar dit mag ook geen verschil maken. In een topic van ubuntuforums (zie #3) werd nog een oplossing aangedragen met het plaatsen van wijzigingen in de sysctl.conf. Dit hebben we ook getest en maakt ook geen verschil.

Wanneer wij data downloaden vanaf de lokale backup of development server van onze backup server in Amsterdam of onze database/fileserver in Amsterdam gaat het een hele tijd goed en vervolgens stalled het rond de 40 MB. Wanneer wij eenzelfde download doen vanaf de lokale development of backup server van een andere server, dan haal ik de kopie volledig binnen. In dit geval was het een test van 1000-en bestanden uiteenlopend van enkele bytes tot meerdere MB's. De volledige 1300 MB is op deze manier binnen gehaald.

Alle kopie scenario's zijn uitgevoerd met scp. Omdat rsnapshot gebruik maakt van scp hoeven we dus eerst rsnapshot niet te testen. De internetverbinding van @Work is verder volledig transparant. Het meest aparte is ook dat het op de oude locatie altijd heeft gewerkt en dat het op de nieuwe niet meer functioneert.

Ik begrijp dat dit inmiddels een behoorlijk verhaal is geworden. Ik hoop dan ook dat jullie de tijd en moeite willen nemen om mij te helpen met dit probleem. Bij voorbaat mijn dank.

[ Voor 0% gewijzigd door _reboot_ op 29-11-2008 14:09 . Reden: klein typo ]

[Verwijderd]

Dit is wel een heel vreemd probleem Wat ik zou proberen is eens te scp'en in de verbose mode (-v optie) meestal komt er dan wel iets boven water. Mocht dat geen soelaas bieden dan zou je scp kunnen monitoren met strace.

[_reboot_]

We hebben inderdaad al geprobeerd om via verbose te achterhalen wat er fout gaat. Maar hier komt eigenlijk niets naar voren.

Wanneer we verbose aanzetten zien we geen enkele melding. En als we wachten totdat scp een melding gaat geven dan zijn we echt dagen verder. Anders blijft hij er vrolijk op wachten totdat hij verder zou gaan.

We zien dat hij de bestandsgrootte en de chmod mode en dergelijke overgooit. Vervolgens zien we via iptraf op de development server dat er in totaal 1,5 MB wordt verwerkt, maar verder maakt hij het niet af. Voor 6 bestanden waarbij de laatste dus 1,5 MB is, zien we dat hij in totaal zo'n 2 MB aan data verwerkt. De eerste 5 bestanden zijn in totaal nog geen 0,5 MB.

strace is nog een optie die we nog moeten proberen. Als ik hier tijd voor heb zal ik dit morgen nog eens proberen.

[eghie]

Je zou eens de congestion control algoritme kunnen aanpassen op de server.

Zie daarvoor:
http://www.evolution-syst...ogs/matt/view_post&id=30/
http://linuxgazette.net/135/pfeiffer.html

Je zou ook eens met de CLI tool saidar kunnen kijken tijdens het kopieeren of er iets met de load op de server gebeurd of IO gebruik. En zeggen dingen als dmesg nog iets over errors ofzo?

[ Voor 32% gewijzigd door eghie op 29-11-2008 22:44 ]

[_reboot_]

dmesg geeft niets aan. De laatste melding is het actief worden van eth0 omdat we de ethernet kabel rechtstreeks op de internet lijn hadden aangesloten zonder tussenkomst van de router en switch.

Heeft iemand een soort gelijk scenario ooit meegemaakt en waar lag het toen aan? En het belangrijkste: wat was toen de oplossing? Misschien brengt een hint ons nog ergens.

Morgen gaan we testen met strace.

[Spider.007]

Heb je naast scp ook andere protocollen geprobeerd, zoals http of ftp? Het lijkt me vrij sterk dat dit probleem aan de gebruikte software ligt; zoals je zelf ook al aangeeft is er niets veranderd. Het lijkt bijna wel een provider / locatie / hardware probleem namelijk

[ Voor 3% gewijzigd door Spider.007 op 30-11-2008 19:44 ]

[_reboot_]

Dat is inderdaad ook nog wel het vermelden waard. Ik kan zowel via de development machine als via welke andere computer aanwezig op het LAN naar hartelust downloaden en uploaden zonder dat er ook maar iets mis gaat of dat hij stalled of iets dergelijks (of in ieder geval, wij hebben er nog niets van gemerkt).

Het probleem doet zich uitsluitend voor met scp. Ftp-en op die machine gaat ook prima en met wget of zelfs lynx heb ik ook geen probleem ondervonden. Ook met de Apache webserver hebben we ook geen problemen over het LAN of internet.

[ Voor 5% gewijzigd door _reboot_ op 30-11-2008 20:00 ]

[imp-]

Kan je misschien (tijdelijk) beschikken over een andere internetverbinding?
Volgens mij moet het probleem daar ergens te zoeken zijn, aangezien het voorheen wel perfect werkte en dit de enigste verandering is in de setup.

[sam.vimes]

_reboot_ schreef op zaterdag 29 november 2008 @ 14:07:
[...]
Voor de duidelijkheid: in beide scenario's ben ik ingelogd op de backup machine in Amsterdam en voer ik het scp commando uit om data te kopieren van de development of backup machine van ons kantoor naar de backup machine in Amsterdam.

Heb je 't ook de andere kant op geprobeerd: het kopieer-commando geven op de lokale devserver en als bestemming de machine in A'dam?

Wanneer wij data downloaden vanaf de lokale backup of development server van onze backup server in Amsterdam of onze database/fileserver in Amsterdam gaat het een hele tijd goed en vervolgens stalled het rond de 40 MB. Wanneer wij eenzelfde download doen vanaf de lokale development of backup server van een andere server, dan haal ik de kopie volledig binnen. In dit geval was het een test van 1000-en bestanden uiteenlopend van enkele bytes tot meerdere MB's. De volledige 1300 MB is op deze manier binnen gehaald.

Klinkt alsof er ontzettend veel tcp-pakketjes wel verzonden worden maar onderweg op de digitale snelweg verongelukken.
scp geeft een "stalled" bericht als er 5 seconden of zo geen datatransfer is.
Gaat de datatransfer met hikjes (zo nu en dan wel een datarate) of is de "stalled" status permanent?

Hm. Ik zie dat je een andere MTU al geprobeerd hebt.

Alle kopie scenario's zijn uitgevoerd met scp. Omdat rsnapshot gebruik maakt van scp hoeven we dus eerst rsnapshot niet te testen.

Dat is niet helemaal correct: rsnapshot maakt gebruik van rsync.
Heb je al geprobeerd het rsync-commando met de hand uit te voeren?
Dat wordt dan iets als

code:

rsync -av localserver:/some/top/directory/ here/

als je het commando op de server in A'dam geeft; of de andere kant op (van lokaal naar Amsterdam):

code:

rsync -av /some/top/directory/ amsterdam:here/

Probeer het ook eens met een zelfgefabriceerde pipe:

code:

cd here
ssh -n localserver 'cd /some/top/directory && tar -cf - .' | tar -xvf -

Dit verwijdert de scp-layer die over ssh ligt.

[_reboot_]

Allen bedankt voor de reacties.

Wegens drukte hebben we nog niet verder kunnen testen. Waarschijnlijk morgen weer.

[jaapkroe]

He, Ik heb ditzelfde probleem. Met verschillende servers, kon niet fatsoenlijk bestanden kopieren.
Vooral grote bestanden 'stallen' na een tijdje.
Ik heb het idee dat dit misschien een 'ubuntu-bug' is, heb het probleem niet gemerkt onder gentoo.
Maar ik kan me geen duidelijke oorzaak bedenken.

Probeer eens rcp, voor mij werkte dat wel.
Dit is de onveilige oudere broer van scp.
Het lijkt mij dus dat het iets te maken heeft met de encryptie die plaatsvindt (hoewel ssh wel werkt), maar wat de bestandsgrootte er dan mee te maken heeft.... het blijft voor mij een raadsel.

[_reboot_]

jaapkroe schreef op dinsdag 02 december 2008 @ 12:23:
He, Ik heb ditzelfde probleem. Met verschillende servers, kon niet fatsoenlijk bestanden kopieren.
Vooral grote bestanden 'stallen' na een tijdje.
Ik heb het idee dat dit misschien een 'ubuntu-bug' is, heb het probleem niet gemerkt onder gentoo.
Maar ik kan me geen duidelijke oorzaak bedenken.

Probeer eens rcp, voor mij werkte dat wel.
Dit is de onveilige oudere broer van scp.
Het lijkt mij dus dat het iets te maken heeft met de encryptie die plaatsvindt (hoewel ssh wel werkt), maar wat de bestandsgrootte er dan mee te maken heeft.... het blijft voor mij een raadsel.

Is het mogelijk dat je informatie verstrekt over de internet verbinding, kernel en dergelijke?

[Kees]

Het stallen van scp was bij mij te verklaren door een stervende harde schijf..

Doen 'normale' io het wel goed? kun je wel gewoon kopieren op de server? kun je met een andere protocol wel verbinden?

[jaapkroe]

_reboot_ schreef op dinsdag 02 december 2008 @ 12:49:
[...]


Is het mogelijk dat je informatie verstrekt over de internet verbinding, kernel en dergelijke?

Ik heb het met verschillende internet verbindingen gemerkt.
orange ADSL verbinding <-> universiteitsnetwerk (beide kanten op)
UPC kabel verbinding <-> universiteitsnetwerk

Volgens mij ook andere servers waar ik soms mee heb geprobeerd te verbinden maar die adressen weet ik niet meer precies. Ik denk dus niet dat het afhangt van het netwerk, eerder iets lokaals. Ik zit achter mijn laptop: linux 2.6.22-15, x86 versie ubuntu 7.10.
Andere io-streams doen het prima, voor zover ik heb gemerkt, nog meerdere GB vrije ruimte op de schijf en geen berichten in /var/log/messages

[_reboot_]

Helaas is het probleem nog niet opgelost. Ik heb op mijn Linux doos thuis, rsnapshot geïnstalleerd, de config-file een beetje aangepast en hopla het werkt. Heb in 24 uur onze complete server gebackuped.
Ook naar en van de server in A-dam was dit geen enkel probleem.

Ik heb de beide kanten op getest en dit ging zonder problemen (ook een xs4all lijntje).

Verwijderd schreef op zaterdag 29 november 2008 @ 15:36:
Mocht dat geen soelaas bieden dan zou je scp kunnen monitoren met strace.

Ik heb handmatig een rsync commando gestart terwijl ik ook strace heb uitgevoerd. Helaas weet ik niet wat ik hier verder mee kan behalve dat er time-outs optreden.

code:

lstat64("db3.webdev.30-11-2008.gz", 0xbf82b604) = -1 EN        OENT (No such file or directory)
lstat64("db2.webdev.30-11-2008.gz", 0xbf82b604)         = -1 ENOENT (No such file or directory)
lstat64("db1.webdev.30-11-2008.gz", 0xbf82b604) = -1 ENOENT (No su        ch file or directory)
select(5, NULL, [4], [4], {60, 0})      = 1 (out [4], left {60, 0})
write(4, "\1\0\0\0\10\0\2\0\0\0\0\240\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1220) = 1        220
time(NULL)                              = 1228483530
select(7, [6], [], NULL, {60, 0})       = 0 (Timeout)
select(7, [6], [], NULL, {60, 0})       = 0 (Timeout)
select(7, [6], [], NULL, {60, 0})       = 0 (Timeout)
select(7, [6], [], NULL, {60, 0})       = 0 (Timeout)

@ sam.vimes

Heb je al geprobeerd het rsync-commando met de hand uit te voeren?

Inmiddels heb ik dit gedaan. Het lijkt erop dat dit ietsje beter gaat maar dit stopt ook na een paar MB.
Verder kan ik hier geen nuttige informatie uit halen.

code:

cd here
ssh -n localserver 'cd /some/top/directory && tar -cf - .' | tar -xvf -

Mijn linux kennis is beperkt en begrijp het commando niet helemaal, wat het doet en hoe moet ik het gebruiken?

@ Jaapkroe

De zelfde conclusie trek ik ook, dat het niet aan het netwerk kan liggen. Maar waardoor komt het dan? Er moet toch een verklaring voor zijn.

Leven er verder nog ideeën?

[_reboot_]

Even een update:

We hebben zojuist nog een test gedaan met rsync. We hebben de optie --time-out=300 toegevoegd.

code:

sudo rsync -av -4 --timeout=300 user@backupA-DAM:/home/user/test/ /home/user/test/

M.b.v. strace hebben we het proces gemonitord.
De backupserver in A-dam spuugde het volgende uit:

code:

user@backupA-DAM:~$ strace -p 29251
Process 29251 attached - interrupt to quit
select(2, NULL, [1], [1], {59, 980000}) = 0 (Timeout)
rt_sigaction(SIGUSR1, {SIG_IGN}, NULL, 8) = 0
rt_sigaction(SIGUSR2, {SIG_IGN}, NULL, 8) = 0
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 690000})
write(1, "P\0\0\10rsync error: timeout in data"..., 84) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
write(2, "rsync: writefd_unbuffered failed"..., 77) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
rt_sigaction(SIGUSR1, {SIG_IGN}, NULL, 8) = 0
rt_sigaction(SIGUSR2, {SIG_IGN}, NULL, 8) = 0
exit_group(30)                          = ?
Process 29251 detached

De lokale webdev spuugde het volgende nadat de 300 seconden voorbij waren:

code:

io timeout after 300 seconds -- exiting
rsync error: timeout in data send/receive (code 30) at io.c(165) [receiver=2.6.9]
rsync: connection unexpectedly closed (2406 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(454) [generator=2.6.9]

Bij het zoeken naar rsync code 12 in Google bracht ons op: deze website

Misschien schijnt dit nog wat licht op de zaak.

[gertvdijk]

Misschien een netwerkkaart driver issue en misschien zelfs 64-bit specifiek. Ik heb iets soortgelijks meegemaakt op een wat oudere machine met Debian. Bitjes vielen gewoon random om op de PCI bus (VIA chipset) zodra er een bepaalde throughput door moest. Het scheen dat er workarounds zijn gekomen in latere kernels, maar inmiddels is die bak al vervangen. Het probleem deed zich ook voor zodra er werd gebackupt en ook SSH beweerde de verbinding te hebben verloren.

code:

write(2, "rsync: writefd_unbuffered failed"..., 77) = -1 EPIPE (Broken pipe)

Doet me aan iets soortgelijks denken. Is je backupvolume toevallig een ander volume dan waar het OS op draait?

[_reboot_]

Wel raar op zich. Er is qua hardware niets veranderd en zijn alleen op een andere lijn overgestapt.
We hadden zelf al bedacht om volgende week er maar een andere Nic in te zetten.

Als er verder nog suggesties zijn horen we dit natuurlijk graag.