Hallo Liste ich brüte hier an einem Problem mit storeBackup. Unter 9.0 lief das Teil problemlos. Jetzt habe ich 9.2 auf einem AMD 64 installiert und bekomme dauern Fehlermeldungen von storeBackup: ERROR 2005.01.25 00:36:56 6073 could not copy /stB/xxx-1/:28 18246 cannot exec md5sum /stB/xxx-1/users/..... Die Fehlermeldungen sind jeweils ca. 256000 (!) Zeichen lang. Ich habe den beanstandeten md5sum-Aufruf manuell im vi getestet, und er hat tatsächlich Probleme. Kürzt man ihn auf ca 128000 Zeichen, geht es. Diese Zahlen lassen mich irgendwie darauf schließen, dass es hier einen Wert geben muss, der die maximale Argumentlänge oder so etwas definiert. Ich habe aber weder im Manual der bash noch in der Doku zu storebackup so einen Wert gefunden. Der Fehler tritt auf mit dem Original-SuSE-Paket und auch, wenn man storeBackup direkt aus dem Internet zieht. Hat jemand das schon mal erlebt? Oder kennt Ihr einen Parameter, mit dem man in Perl, bash oder storeBackup die Argumentlänge für Programmaufrufe begrenzen kann? Gruß, Wolfgang
Hallo Wolfgang, hallo Leute, Am Dienstag, 25. Januar 2005 12:14 schrieb Wolfgang Hinsch:
ich brüte hier an einem Problem mit storeBackup. Unter 9.0 lief das Teil problemlos. Jetzt habe ich 9.2 auf einem AMD 64 installiert und bekomme dauern Fehlermeldungen von storeBackup:
BTW: Teste mal spasseshalber die StoreBackup-Version von SuSE 9.0. Läuft die unter 9.2?
ERROR 2005.01.25 00:36:56 6073 could not copy /stB/xxx-1/:28 18246 cannot exec md5sum /stB/xxx-1/users/.....
Die Fehlermeldungen sind jeweils ca. 256000 (!) Zeichen lang. Ich habe den beanstandeten md5sum-Aufruf manuell im vi getestet, und er hat tatsächlich Probleme. Kürzt man ihn auf ca 128000 Zeichen, geht es.
Das könnte irgend ein Problem bezüglich 32/64 bit zu sein, möglicherweise auch in Zusammenhang mit utf-8. Genaueres kann ich Dir aber auch nicht sagen. Bei mir (32bit-System, utf-8 deaktiviert) funktioniert StoreBackup übrigens problemlos.
Hat jemand das schon mal erlebt?
Ja - "Möbius" hat am 18.1. unter dem Subject "storeBackup, md5sum, endlose Datensatzlänge" genau das gleiche Problem beschrieben. Bei ihm war es auch ein 64bit-Prozessor. Ist Dein System eine reine 64bit-Installation (zumindest in Bezug auf Basissystem und Perl)? UTF-8 oder ISO-8859-15? (-> locale) Gruß Christian Boltz --
Bitte? Ich glaub ich steh im Wald! wenn rings um dich lauter Bäume sind dann hast Du vermutlich recht. [> David Haller und Bernhard Walle in suse-linux]
Hallo Christian, hallo Liste Am Donnerstag, 27. Januar 2005 01:20 schrieb Christian Boltz:
Am Dienstag, 25. Januar 2005 12:14 schrieb Wolfgang
Hinsch:
ich brüte hier an einem Problem mit storeBackup. Unter 9.0 lief das Teil problemlos. Jetzt habe ich 9.2 auf einem AMD 64 installiert und bekomme dauern Fehlermeldungen von storeBackup:
BTW: Teste mal spasseshalber die StoreBackup-Version von SuSE 9.0. Läuft die unter 9.2?
Ich hatte zuerst die Version Stand ca 9/04 direkt von der storeBackup-Seite benutzt. Es trat exakt der gleiche Fehler auf. Das Teil lief aber bis Ende Dezember unter 8.1 fehlerfrei. Die Fehler traten erst auf, als es unter 9.2/64Bit laufen sollte.
ERROR 2005.01.25 00:36:56 6073 could not copy /stB/xxx-1/:28 18246 cannot exec md5sum /stB/xxx-1/users/.....
Die Fehlermeldungen sind jeweils ca. 256000 (!) Zeichen lang. Ich habe den beanstandeten md5sum-Aufruf manuell im vi getestet, und er hat tatsächlich Probleme. Kürzt man ihn auf ca 128000 Zeichen, geht es.
Das könnte irgend ein Problem bezüglich 32/64 bit zu sein, möglicherweise auch in Zusammenhang mit utf-8. Genaueres kann ich Dir aber auch nicht sagen.
Bei mir (32bit-System, utf-8 deaktiviert) funktioniert StoreBackup übrigens problemlos.
Hat jemand das schon mal erlebt?
Ja - "Möbius" hat am 18.1. unter dem Subject "storeBackup, md5sum, endlose Datensatzlänge" genau das gleiche Problem beschrieben. Bei ihm war es auch ein 64bit-Prozessor.
Ähm, da muss ich mich jetzt outen. Ich hatten meine Internetstation neu installiert mit 9.2 und die Konfig-Dateien aus 9.0 rübergezogen. Die Mailadressen hatte ich nicht gefunden, aber bei weniger als 10 geht das Neueingeben schneller als die Suche. Bei dem Namen hat mich das Kamel wohl irgendwie missverstanden...
Ist Dein System eine reine 64bit-Installation (zumindest in Bezug auf Basissystem und Perl)? UTF-8 oder ISO-8859-15? (-> locale)
Beides. Zuerst hatte ich es mit UTF-8 versucht. Danach mit env auf ISO-8859-15. Bei beiden tritt der Fehler auf. Es ist auch egal, ob ich die unter 8.1 einwandfreie Version oder die neue von SuSE nehme (die über die 64-Schiene nachinstalliert wurde). Zur Zeit installiere ich auf dem Rechner SuSE 9.2/32 parallel, um zu testen, ob der Fehler dann beseitigt ist. Glücklicherweise lass ich immer Platz für eine gleichgroße Rootpartition frei. Ich weiß aber nicht recht, ob ich mir wünschen soll, dass es das war, denn dann muss ich den Hobel mit 32 fahren:( Gruß und danke, Wolfgang
Hallo Wolfgang, hallo Leute, Am Donnerstag, 27. Januar 2005 10:22 schrieb Wolfgang Hinsch:
Am 27. Januar 2005 01:20 schrieb Christian Boltz:
Am 25. Januar 2005 12:14 schrieb Wolfgang Hinsch:
ich brüte hier an einem Problem mit storeBackup. Unter 9.0 lief das Teil problemlos. Jetzt habe ich 9.2 auf einem AMD 64 installiert und bekomme dauern Fehlermeldungen von storeBackup:
BTW: Teste mal spasseshalber die StoreBackup-Version von SuSE 9.0. Läuft die unter 9.2?
Ich hatte zuerst die Version Stand ca 9/04 direkt von der storeBackup-Seite benutzt. Es trat exakt der gleiche Fehler auf. Das Teil lief aber bis Ende Dezember unter 8.1 fehlerfrei. Die Fehler traten erst auf, als es unter 9.2/64Bit laufen sollte.
Das deutet also schonmal auf ein 64bit-Problem hin. Vermutlich in Perl, da es ja mit derselben StoreBackup-Version unter SuSE 8.1 funktioniert hat.
ERROR 2005.01.25 00:36:56 6073 could not copy /stB/xxx-1/:28 18246 cannot exec md5sum /stB/xxx-1/users/.....
Die Fehlermeldungen sind jeweils ca. 256000 (!) Zeichen lang. Ich habe den beanstandeten md5sum-Aufruf manuell im vi getestet, und er hat tatsächlich Probleme. Kürzt man ihn auf ca 128000 Zeichen, geht es.
Das könnte irgend ein Problem bezüglich 32/64 bit zu sein, möglicherweise auch in Zusammenhang mit utf-8. Genaueres kann ich Dir aber auch nicht sagen.
Bei mir (32bit-System, utf-8 deaktiviert) funktioniert StoreBackup übrigens problemlos.
Hat jemand das schon mal erlebt?
Ja - "Möbius" hat am 18.1. unter dem Subject "storeBackup, md5sum, endlose Datensatzlänge" genau das gleiche Problem beschrieben. Bei ihm war es auch ein 64bit-Prozessor.
Ähm, da muss ich mich jetzt outen. Ich hatten meine Internetstation neu installiert mit 9.2 und die Konfig-Dateien aus 9.0 rübergezogen. Die Mailadressen hatte ich nicht gefunden, aber bei weniger als 10 geht das Neueingeben schneller als die Suche. Bei dem Namen hat mich das Kamel wohl irgendwie missverstanden...
Ach so ;-)
Ist Dein System eine reine 64bit-Installation (zumindest in Bezug auf Basissystem und Perl)? UTF-8 oder ISO-8859-15? (-> locale)
Beides. Zuerst hatte ich es mit UTF-8 versucht. Danach mit env auf ISO-8859-15. Bei beiden tritt der Fehler auf. Es ist auch egal, ob ich die unter 8.1 einwandfreie Version oder die neue von SuSE nehme (die über die 64-Schiene nachinstalliert wurde).
Gut, dann wäre das auch geklärt.
Zur Zeit installiere ich auf dem Rechner SuSE 9.2/32 parallel, um zu testen, ob der Fehler dann beseitigt ist. Glücklicherweise lass ich immer Platz für eine gleichgroße Rootpartition frei. Ich weiß aber nicht recht, ob ich mir wünschen soll, dass es das war, denn dann muss ich den Hobel mit 32 fahren:(
Das Ergebnis würde mich wiederum interessieren ;-) Bitte mit identischer Paketliste und gleichen Dateien in /etc testen, um andere Fehlerursachen so weit wie möglich auszuschließen. Ein möglicher Workaround wäre, in storeBackup.pl $main:execParamLength entsprechend anzupassen. Da wir gerade dabei sind: Guck mal im StoreBackup-Log nach einem Eintrag a la "setting ARG_MAX to ...." (Note: diesen Absatz habe ich nur aufgrund kurzer, ausschnittweiser Lektüre von storeBackup.pl geschrieben - er könnte also auch komplett falsch sein ;-) Gruß Christian Boltz PS: Ich quote absichtlich so ausführlich, damit ich den Text für einen Bugreport nicht aus mehreren Mails zusammensammeln muss ;-) -- Oh großer Meister! Darf man euch untertänigst darauf aufmerksam machen, daß das diff'en von Postscriptfonts komplette Unterordner synchronisiert und diff't, unter Berücksichtigung von Links? :-) [Ratti in fontlinge-devel]
Hallo, Am Fri, 28 Jan 2005, Christian Boltz schrieb:
Am Donnerstag, 27. Januar 2005 10:22 schrieb Wolfgang Hinsch:
Am 27. Januar 2005 01:20 schrieb Christian Boltz:
Am 25. Januar 2005 12:14 schrieb Wolfgang Hinsch:
ich brüte hier an einem Problem mit storeBackup. Unter 9.0 lief das Teil problemlos. Jetzt habe ich 9.2 auf einem AMD 64 installiert und bekomme dauern Fehlermeldungen von storeBackup:
BTW: Teste mal spasseshalber die StoreBackup-Version von SuSE 9.0. Läuft die unter 9.2?
Ich hatte zuerst die Version Stand ca 9/04 direkt von der storeBackup-Seite benutzt. Es trat exakt der gleiche Fehler auf. Das Teil lief aber bis Ende Dezember unter 8.1 fehlerfrei. Die Fehler traten erst auf, als es unter 9.2/64Bit laufen sollte.
Das deutet also schonmal auf ein 64bit-Problem hin. Vermutlich in Perl, da es ja mit derselben StoreBackup-Version unter SuSE 8.1 funktioniert hat.
Jup. Was ist die Ausgabe von: perl -V:archname Wenn dort nicht ein Teil '64all' auftaucht, ist die Ursache evtl. schon gefunden. Bei mir ist das, auf nem 32bit Athlon auch schon: archname='i686-linux-64all-ld'; allerdings hab ich mein perl-5.8.0 selber kompiliert, was weniger schwierig ist, als man glaubt. -dnh -- I know I can't see sanity in the rear view mirror any more. -- stevo
Hallo Liste ich hatte noch mit einem Uralt-Server zu kämpfen und komme erst jetzt dazu, das storeBackup-Problem weiter auseinander zu nehmen. Am Freitag, 28. Januar 2005 01:50 schrieb David Haller:
Hallo,
Am Fri, 28 Jan 2005, Christian Boltz schrieb:
Am Donnerstag, 27. Januar 2005 10:22 schrieb Wolfgang Hinsch:
Ich hatte zuerst die Version Stand ca 9/04 direkt von der storeBackup-Seite benutzt. Es trat exakt der gleiche Fehler auf. Das Teil lief aber bis Ende Dezember unter 8.1 fehlerfrei. Die Fehler traten erst auf, als es unter 9.2/64Bit laufen sollte.
Das deutet also schonmal auf ein 64bit-Problem hin. Vermutlich in Perl, da es ja mit derselben StoreBackup-Version unter SuSE 8.1 funktioniert hat.
Jup. Was ist die Ausgabe von:
perl -V:archname
Wenn dort nicht ein Teil '64all' auftaucht, ist die Ursache evtl. schon gefunden. Bei mir ist das, auf nem 32bit Athlon auch schon:
archname='i686-linux-64all-ld';
archname='x86_64-linux-thread-multi' ich hatte schon gehofft, das wärs :(
allerdings hab ich mein perl-5.8.0 selber kompiliert, was weniger schwierig ist, als man glaubt.
Hallo, Am Mon, 31 Jan 2005, Wolfgang Hinsch schrieb:
Am Freitag, 28. Januar 2005 01:50 schrieb David Haller:
Am Fri, 28 Jan 2005, Christian Boltz schrieb:
Am Donnerstag, 27. Januar 2005 10:22 schrieb Wolfgang [..]
Ich hatte zuerst die Version Stand ca 9/04 direkt von der storeBackup-Seite benutzt. Es trat exakt der gleiche Fehler auf. Das Teil lief aber bis Ende Dezember unter 8.1 fehlerfrei. Die Fehler traten erst auf, als es unter 9.2/64Bit laufen sollte.
Das deutet also schonmal auf ein 64bit-Problem hin. Vermutlich in Perl, da es ja mit derselben StoreBackup-Version unter SuSE 8.1 funktioniert hat.
Jup. Was ist die Ausgabe von:
perl -V:archname
Wenn dort nicht ein Teil '64all' auftaucht, ist die Ursache evtl. schon gefunden. Bei mir ist das, auf nem 32bit Athlon auch schon:
archname='i686-linux-64all-ld';
archname='x86_64-linux-thread-multi'
ich hatte schon gehofft, das wärs :(
Hast du das "nicht" ueberlesen? Ich weiss allerdings nicht, ob das auf einem 64bit System auch dargestellt wird, da dort 64bit ja default waere. Ist die Ausgabe von $ perl -e 'print 2**31 * 256, "\n"' 549755813888 auch bei dir obiges? Und was kommt bei perl -V:use64bitint -V:use64bitall -V:uselongdouble -V:cppflags -dnh -- No sig today
Hallo David, Am Montag, 31. Januar 2005 20:46 schrieb David Haller:
Am Mon, 31 Jan 2005, Wolfgang Hinsch schrieb:
Am Freitag, 28. Januar 2005 01:50 schrieb David Haller:
Jup. Was ist die Ausgabe von:
perl -V:archname
Wenn dort nicht ein Teil '64all' auftaucht, ist die Ursache evtl. schon gefunden. Bei mir ist das, auf nem 32bit Athlon auch schon:
archname='i686-linux-64all-ld';
archname='x86_64-linux-thread-multi'
ich hatte schon gehofft, das wärs :(
Hast du das "nicht" ueberlesen? Ich weiss allerdings nicht, ob das auf einem 64bit System auch dargestellt wird, da dort 64bit ja default waere.
Ist die Ausgabe von
$ perl -e 'print 2**31 * 256, "\n"' 549755813888
549755813888
auch bei dir obiges? Und was kommt bei
perl -V:use64bitint -V:use64bitall -V:uselongdouble -V:cppflags
use64bitint='define' use64bitall='define' uselongdouble='undef' cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno_strict_aliasing -pipe'; Gibt es auch einen Parameter für maximale Zeilenlänge oder maximale Übergabeparameter an Funktionen? Wenn man die Zeilenlänge auf ca 128000 Zeichen begrenzen könnte, wäre das evtl ein Workaround. Gruß, Wolfgang
Hallo, Am Tue, 01 Feb 2005, Wolfgang Hinsch schrieb: [..]
Gibt es auch einen Parameter für maximale Zeilenlänge oder maximale Übergabeparameter an Funktionen? Wenn man die Zeilenlänge auf ca 128000 Zeichen begrenzen könnte, wäre das evtl ein Workaround.
Ja, gibt es, das ist schon im Kernel/der Shell definiert. Ich habe jetzt nochmal nachgeschaut, der eigentliche Fehler war ja, dass md5sum eine zu lange Kommandozeile uebergeben wurde und somit nicht ausgefuehrt werden konnte. Kannst du evtl. mal den Returncode ueberpruefen, der muesste eigentlich 'E2BIG' "Argument list too long" sein. Was die Begrenzung angeht: das muesste man eigentlich vorher machen, denn der Fehler kommt _wegen_ der Begrenzung. Woher kommen eigentlich diese pervers langen Dateinamen? -dnh -- 39: EBCDIC an american data encryption standard (nach terra)
Hallo, Am Dienstag, 1. Februar 2005 15:10 schrieb David Haller:
Am Tue, 01 Feb 2005, Wolfgang Hinsch schrieb: [..]
Gibt es auch einen Parameter für maximale Zeilenlänge oder maximale Übergabeparameter an Funktionen? Wenn man die Zeilenlänge auf ca 128000 Zeichen begrenzen könnte, wäre das evtl ein Workaround.
Ja, gibt es, das ist schon im Kernel/der Shell definiert.
Ich habe jetzt nochmal nachgeschaut, der eigentliche Fehler war ja, dass md5sum eine zu lange Kommandozeile uebergeben wurde und somit nicht ausgefuehrt werden konnte. Kannst du evtl. mal den Returncode ueberpruefen, der muesste eigentlich 'E2BIG' "Argument list too long" sein.
126 Argument list too long
Was die Begrenzung angeht: das muesste man eigentlich vorher machen, denn der Fehler kommt _wegen_ der Begrenzung. Woher kommen eigentlich diese pervers langen Dateinamen?
Die sind eigentlich gar nicht so lang, nur so um die 180 Zeichen. Aber er will 1423 (!) Filenamen gleichzeitig übergeben. Und dann streikt md5sum. Die Begrenzung wollte ich eigentlich so angeben, dass storeBackup sich mäßigt. Wo hat der Bengel eigentlich diesen riesigen Wert für die Zeilenlänge oder Argumentliste her?? Ich teste zur Zeit auf der 32-Bit-Seite. Das wird aber so um die 5 Stunden dauern. Gruß, Wolfgang
Hallo, Am Tue, 01 Feb 2005, Wolfgang Hinsch schrieb:
Am Dienstag, 1. Februar 2005 15:10 schrieb David Haller:
Am Tue, 01 Feb 2005, Wolfgang Hinsch schrieb: [..]
Gibt es auch einen Parameter für maximale Zeilenlänge oder maximale Übergabeparameter an Funktionen? Wenn man die Zeilenlänge auf ca 128000 Zeichen begrenzen könnte, wäre das evtl ein Workaround.
Ja, gibt es, das ist schon im Kernel/der Shell definiert.
Ich habe jetzt nochmal nachgeschaut, der eigentliche Fehler war ja, dass md5sum eine zu lange Kommandozeile uebergeben wurde und somit nicht ausgefuehrt werden konnte. Kannst du evtl. mal den Returncode ueberpruefen, der muesste eigentlich 'E2BIG' "Argument list too long" sein.
126 Argument list too long
*g*
Was die Begrenzung angeht: das muesste man eigentlich vorher machen, denn der Fehler kommt _wegen_ der Begrenzung. Woher kommen eigentlich diese pervers langen Dateinamen?
Die sind eigentlich gar nicht so lang, nur so um die 180 Zeichen. Aber er will 1423 (!) Filenamen gleichzeitig übergeben. Und dann streikt md5sum.
Achso. Das ist dann ein Fehler von StoreBackup.
Die Begrenzung wollte ich eigentlich so angeben, dass storeBackup sich mäßigt. Wo hat der Bengel eigentlich diesen riesigen Wert für die Zeilenlänge oder Argumentliste her??
Keine Ahnung. Normal wird die von configure abgefragt, aber viele Programme verwenden die wohl nicht. Da muesste man sich mal SB selber anschauen, wie md5sum aufgerufen wird. Ausserdem ist das eh eigenartig, denn perl bringt Digest::MD5 mit. Und SB ist doch in perl, oder? So, ich hab mir jetzt storeBackup mal runtergeladen. Du kannst die Parameterlaenge in StoreBackup.pl aendern. Schau bitte mal in die Logdatei, wenn du dort einen Infostring in der Art: setting ARG_MAX to <WERT> und die Ausgabe von 'uname' "Linux" ist, dann kannst du in Zeile 125 den Wert hinter "'Linux' => " anpassen: my (%execParamLength) = ('AIX' => 22 * 1024, 'Linux' => 124 * 1024); Ich wuerde mal '120 * 1024' probieren, und dann '60 * 1024'. Bei mir ist die maximale Laenge 64 kB... Schau mal, ob du in einem config.log den string 'checking the maximum length of command line arguments' findest, den Wert kannst du dann verdoppeln und dann auf ganze KB abrunden (bzw. noch etwas mehr abziehen). HTH, -dnh -- "DOS=HIGH ...I knew it was on something!" (UNIX user, while reading C:\CONFIG.SYS)
Hallo, Am Dienstag, 1. Februar 2005 21:02 schrieb David Haller:
Am Tue, 01 Feb 2005, Wolfgang Hinsch schrieb:
Am Dienstag, 1. Februar 2005 15:10 schrieb David Haller:
Ich habe jetzt nochmal nachgeschaut, der eigentliche Fehler war ja, dass md5sum eine zu lange Kommandozeile uebergeben wurde und somit nicht ausgefuehrt werden konnte. Kannst du evtl. mal den Returncode ueberpruefen, der muesste eigentlich 'E2BIG' "Argument list too long" sein.
126 Argument list too long
*g*
Was die Begrenzung angeht: das muesste man eigentlich vorher machen, denn der Fehler kommt _wegen_ der Begrenzung. Woher kommen eigentlich diese pervers langen Dateinamen?
Die sind eigentlich gar nicht so lang, nur so um die 180 Zeichen. Aber er will 1423 (!) Filenamen gleichzeitig übergeben. Und dann streikt md5sum.
Achso. Das ist dann ein Fehler von StoreBackup.
Die Begrenzung wollte ich eigentlich so angeben, dass storeBackup sich mäßigt. Wo hat der Bengel eigentlich diesen riesigen Wert für die Zeilenlänge oder Argumentliste her??
Keine Ahnung. Normal wird die von configure abgefragt, aber viele Programme verwenden die wohl nicht. Da muesste man sich mal SB selber anschauen, wie md5sum aufgerufen wird.
Ausserdem ist das eh eigenartig, denn perl bringt Digest::MD5 mit. Und SB ist doch in perl, oder?
So, ich hab mir jetzt storeBackup mal runtergeladen. Du kannst die Parameterlaenge in StoreBackup.pl aendern. Schau bitte mal in die Logdatei, wenn du dort einen Infostring in der Art:
setting ARG_MAX to <WERT>
und die Ausgabe von 'uname' "Linux" ist, dann kannst du in Zeile 125 den Wert hinter "'Linux' => " anpassen:
my (%execParamLength) = ('AIX' => 22 * 1024, 'Linux' => 124 * 1024);
Ich wuerde mal '120 * 1024' probieren, und dann '60 * 1024'.
Treffer, versenkt! Ich habe ihn auf 62 * 1024 gesetzt, die Länge war nach vi-Test um Faktor 2 zu groß. Jetzt läuft es! Ich vermute mal, dass das ganze irgendwo mit einem Faktor 2 zusammenhängt, der die maximale Größe von char beschreibt und bisher durch 8 Bit immer auf 1 stand, jetzt aber für UTF-8 auf 2 steht. An 32/64-Bit liegt es nicht, denn eine Parallelinstallation eines 9.2 mit 32 Bit bringt denselben Fehler. Möglicherweise gibt es da in anderen Funktionen auch noch Wirkungen, denn ein Kollege berichtete von ähnlichen Problemen in einem anderen Script, aber dafür melde ich mit ggf. nochmal. Vielen Dank allen die geholfen haben, insbesondere auch an David. Gruß und schönen Abend, Wolfgang
Hallo Christian, Am Freitag, 28. Januar 2005 00:10 schrieb Christian Boltz:
Ein möglicher Workaround wäre, in storeBackup.pl $main:execParamLength entsprechend anzupassen. Da wir gerade dabei sind: Guck mal im StoreBackup-Log nach einem Eintrag a la "setting ARG_MAX to ...." (Note: diesen Absatz habe ich nur aufgrund kurzer, ausschnittweiser Lektüre von storeBackup.pl geschrieben - er könnte also auch komplett falsch sein ;-)
Das habe ich gerade beim nochmal querlesen gefunden... Du hast die Lösung hier schon aufgezeigt, sie war nur bei mir irgendwie vorbeigerutscht. Ich war wohl zu fixiert darauf, das das Problem mit 32 Bit erledigt wäre, was es nicht war. Vielleicht sollte ich mich mal mit perl beschäftigen, aber die Zeit... Wie in meiner anderen Mail geschrieben, die Lösung war hier das Umsetzen von 124 * 1024 auf 62 * 1024 in Zeile 126. Vielen Dank, Wolfgang
participants (3)
-
Christian Boltz -
David Haller -
Wolfgang Hinsch