Beiträge von HELO

Zitat von [netcup] Alex

Ist für die IP des vServers ein ordentlich rDNS gesetzt welcher wiederum auf die IP des Servers auflöst? Das bitte einmal prüfen.

Jepp. rDNS der ServerIP zeigt auf Absender-MailDomain und umgekehrt (via CCP). Ist übrigens eine managed vserver variante, daher habe ich auf den mailversand via vxxxxxx.yourvserver.net (selbe IP) keinen Einfluss, sollte aber auch nicht das Problem sein.

Betrifft wie gesagt nur Arcor, und offenbar (siehe link oben) auch von Freemailern wie GMX, WEB.de, etc. Mails zu AOL, Hotmail, usw. ohne jegliche Probleme (die erfahrungsgemäß noch anfälliger sind), zudem tauchen die Rückläufer nur zufällig auf.

Habe wie vmk den Verdacht, dass einige Arcor-mailserver untereinander nicht kommunizieren und sich gegenseitig nicht akzeptieren (z.B. arcor.de akzeptiert mail über den Server arcor-online.net nicht - was schon lustig ist.

Gestern Abend hatte ich noch das Vergnügen über die Vodafone (Muttergesellschaft) Geschäftskundenhotline einen ahnungslosen Mitarbeiter über die Probleme detailliert zu informieren. Heute jedenfalls traten besagte Rückläufer immernoch vereinzelt auf.

hallo zusammen,

seit kurzem kommen nach gesendeten mails an arcor-adressen "relay access denied" rückläufer, was eigentlich ungewöhnlich ist und auf ein problem seitens arcor schließen lässt.

Reporting-MTA: dns; mail-in-11.arcor-online.net
X-Postfix-Queue-ID: AD5A835A977
X-Postfix-Sender: rfc822; web0@vxxxxxx.yourvserver.net
Arrival-Date: Mon, 16 Jul 2012 22:57:54 +0200 (CEST)




Final-Recipient: rfc822; xxxxx@arcor.de
Original-Recipient: rfc822;xxxxx@arcor.de
Action: failed
Status: 5.7.1
Remote-MTA: dns; mail-z2.arcor-online.net
Diagnostic-Code: smtp; 554 5.7.1 <xxxxx@arcor.de>: Relay access denied

hat jemand ähnliche erfahrungen? blacklisting und mailserver-probleme seitens netcup dürften eigentlich dabei wohl kaum die ursache sein, oder?:

Das problem scheinen jedenfalls noch mehrere leute zu haben:

Mails an Arcor Adressen werden nicht zugestellt

weiß jemand was genaueres dazu?

So, Neues aus der Anstalt:

Bin gerade über diesen sehr hilfreichen Eintrag von letztem Monat gestoßen (der bisher einzige in der gesamten Google-Welt):

Zitat

7 is "time up" and 14 is "EOF", so the root cause of this is probably a read timeout during the upload.

The 70000 prefix means they are APR status codes.

They are logged poorly here because they the core of apache is expecting a different type of error code then what is returned -- these are APR or "filter" return codes but the core of httpd is expecting a HTTP status code or 0 for OK.

apache2 - Handler for (null) returned invalid result code 70007 / causing error 500? - Server Fault

Nachdem mir hierzu der Netcup-Support vor einiger Zeit unmissverständlich mitteilte, dass man für individuelle Software-Probleme keinen Support leistet, möchte ich hier nochmals betonen, dass das definitiv kein Software-Problem ist, sondern allem Anschein nach ein Apache-/Netzwerk-/Proxy-Kommunikationsproblem. Das erklärt übrigens auch, warum das nicht gezielt reproduzierbar ist sondern nur sporadisch auftritt, insbesondere ausschließlich bei POST-Eingaben (Variablen und Dateiübertragungen).

Weitere Hilfen und Hinweise sind willkommen! (wir sind inzwischen bei der "Profi-Frage", s.o.)

Dieses Problem betrifft übrigens auch und insbesondere die managed-Varianten, bei denen man als User bei einem Neustart so gut wie keine direkten Eingriffs- und Steuerungsmöglichkeit hat. Bei mir kam es bei einem Server-Neustart auch schon zu fehlerhaften MySQL-tables und sogar Datenverlusten.

Daher wäre eine allgemeine Verbesserung diesbezüglich sehr wünschenswert, um solche Ärgernisse bei notwendigen Neustarts möglichst ausschließen zu können.

Zitat von ToXXiQ

HELO: Wenn du keine Grundsatzdiskussion starten willst, dann provoziere Sie bitte nicht durch Aussagen deinerseits. (Atommüll im Garten usw.) Oder möchtest du ein Windrad im Garten stehen haben?

Das ist wahr, ich ziehe die Aussage zurück (ich möchte insbesondere auch kein Staudamm im Garten stehen haben :))

Zitat von ToXXiQ

Bei der Zertifizierung gebe ich dir rein Wettbewerbsrechtlich vollkommen Recht, hier fehlen die Nachweise.

Danke, darauf kommt's mir an

Ul1c: Ich glaube nicht, dass wir hier eine Grundsatzdiskussion über unterschiedliche Stromerzeugungen starten sollten.

Es geht mir darum: Netcup wirbt mit Ökostrom. Ich habe noch keinen Provider gesehen, der mit Atomstrom wirbt. Das hat einen Grund: Ökostrom ist in der Öffentlichkeit positiv belegt, und grundsätzlich auch als zukunftsorientiert angesehen. Ob das stromtechnisch sinnvoll ist, braucht man hier nicht zu diskutieren. [unnötige Anmerkung entfernt]

Und diesen Positivismus hinter Ökostrom nutzt nicht nur Netcup gerne, sondern auch manche seiner Kunden. Dies verschafft einem Image-Vorteile gegenüber Mitbewerbern, die dies nicht anbieten. Diese Vorteile sind "Wettbewerbsvorteile" und unterliegen daher dem Wettbewerbsrecht. Dieses Wettbewerbsrecht untersagt allerdings unlautere Werbung bzw. Aussagen, die nicht auch fundiert bestätigt werden können. D.h.: Wenn man behauptet, einen Anbieter mit Ökostrom zu nutzen, dann muss man das auch belegen können - ansonsten begibt man sich auf rechtlich sehr dünnes Eis. Ein einfacher Link zur Netcup-Ökostrom-Seite ist zwar schön, dient aber nicht als Beleg. Dabei wird lediglich von einer Aussage zur nächsten verwiesen.

Diese fundierte Belegmöglichkeit (Zertifikat) fehlt uns als Kunden, da Netcup das bisher nicht ausreichend transparent zugänglich macht. Darum geht es mir - und ich hoffe sehr in unser aller Interesse , dass sich dies bald zum besseren ändert.

Zitat von beyercenter

Also mein Server war um die selbe Zeit komplett nicht erreichbar.

Sieht so aus, betraf auch mein managed vserver. Zwischen ca. 10:06 und 10:44 Uhr (laut access-logs und VCP-Runtime). Hat dort auch zu DB-Inkonsistenzen geführt, mit Datenverlust

Support klärt das wohl gerade...

Hey, wieso markiert hier jemand das Thema als erledigt, obwohl die Sache noch immer so ungeklärt ist wie am Anfang
Wenn das "erledigt" ist, dann hätte ich doch noch ein paar ganz einfache Fragen dazu:

Simple Frage: Wie entstehen solche "invalid result code" Rückmeldungen allgemein?
Anspruchsvollere Frage: Was bedeuten die codes 70007 und 70014 ?
Profi Frage: Was kann man dagegen tun?

Ich möchte (nach bereits direkter Mitteilung an den Support im Vorfeld meines Vertrages) an dieser Stelle nochmals darum bitten, den Ökostrom noch etwas transparenter zu gestalten.

- welcher konkrete Anbieter?
- Zertifiziert (z.B. OK-Strom)? Wenn ja, Zertifikat online bereitgestellt?

(siehe hierzu z.B. Hetzner oder auch all-inkl., die das transparent und vorbildlich gestalten).

Das Thema Ökostrom wird immer wichtiger, auch als Website-Anbieter geht man damit gerne in die Außendarstellung. Hierzu wird es zunehmend wichtig, seinen Kunden auch entsprechende Transparenz zugänglich zu machen. Aussagen wie "mein Provider behauptet das" sind ohne weitere Belegmöglichkeiten auch wettbewerbsrechtlich nicht sonderlich dienlich.

Das mal als Anregung, ich hoffe das das in naher Zukunft aufgegriffen und verbessert wird

Süß...

Nun ja, anstatt bei jedem Bild-Aufruf die Berechnung mitsamt Datenabruf und Bildgenerierung durchzuführen, wäre eine direkte Lieferung der gecachten Bilddatei doch vorteilhafter, oder?

diagramm.php?id=342342134

Script diagramm.php guckt nach, ob unter der id 342342134 bereits ein Bild im Filecache abgelegt ist, z.B. "342342134.jpg", und gibt das aus. Falls nicht, oder falls eine Neu-Generierung erzwungen wird (z.B. wenn das gecachte File älter als 24 Stunden ist - siehe 'filemtime') wirds neu generiert, gecacht und ausgegeben. Simple und spart Ressourcen.

Dann würde ich aber gleich das generierte Bild cachen, dann kannst die Bildgenerierung auch serverseitig in gewissen Abständen updaten (manuell oder per cron) und kannst Dir die Datenbank sparen, wenn Du die Daten sonst nicht für weitere Dinge brauchst

Der einzige (mir bekannte) Umweg wäre mit POST-Übergabe, was aber so als direkter image-Aufruf natürlich nicht funktioniert.

Am besten wäre wohl
- Variablen zwischenspeichern (z.B. Filecache oder DB) und per ID-abrufen (diagramm.php?id=short)

Oder besonders elegant per AJAX-call nachdem die Hauptseite geladen wurde, Daten per POST nicht vergessen.

Aha, wäre mein nächster Tipp gewesen: Zuviele Parameter in der Url (ich würde ne andere Lösung und die Variablen nicht per $_GET übergeben - z.B. entweder function call mit vorhandenen variablen, oder Variablen-Generierung aus dem script heraus - Also Daten und Script nicht trennen, wenn's nicht sein muss).

Schwer zu sagen, da mir hier Praxiswerte fehlen. Kann natürlich auch an anderen Faktoren liegen, max_execution_time, etc. Error-Log mal eingeschaltet und reingeschaut?

Zitat von Knutella

Bei einer X-Aches bis 1.000 geht das noch wunderbar, aber bereits bei 2.000 kommt nach einer Zeit nur noch ein kleines leeres Kästchen.

Was sagen denn die serverseitigen Error-Logs? Da pChart die Daten grafisch mit der GD-Lib aufbereitet, ist die Wahrscheinlichkeit recht hoch, dass Dir bei sovielen Datenpunkten das memory_limit nicht ausreicht.

Ja Danke erstmal! Ich bin mir bewusst, dass das so vage schwer zu beantworten ist (mir würde es ja schon reichen wenn mal irgendwo dokumentiert wäre, was diese return codes an sich bedeuten bzw. wie diese serverseitig technisch überhaupt entstehen.)

Gestern wurde ich auch dazu per PN dazu angeschrieben, mit dem Hinweise dass das bei Google-Suche eine Vielzahl Ursachen haben kann. Hier nochmals die Rahmenbedingungen in meinem konkreten Fall:

- Es liegt nicht am Coding ansich
- Der Fehler ist nicht reproduzierbar
- Der Fehler tritt nur bei wiederholt-getimeten AJAX-Calls via POST auf, und wenn dann oft nur einmalig.
- Der Fehler tritt extrem selten auf.

Daher scheiden mal vorneweg 99% der bei Google auffindbaren Gründe aus.

Was bleibt ist die Möglichkeit, dass
- manche Client-Router/Proxies in speziellen Konstellationen abblocken
- Scripte unmittelbar/exakt beim Aufruf wieder abgebrochen werden (das würde die Seltenheit erklären)
- oder was ganz anderes.

Und darum geht's mir: Herauszufinden, an was das liegen kann. Und einzuschätzen, ob es relevant zum debuggen/optimieren ist, oder man schlicht damit als Phänomen leben muss.

Zum eigentlichen Coding:
Die PHP-Scripts werden über JQuery (1.6.2) mit $.ajax aufgerufen, Variablen per POST gesendet, und zwar minütlich per setInterval

$(document).ready(function(){setInterval(function(){var a=$("#load tr:first").attr("id");getnew(a)},6E4)});
function getnew(a){$.ajax({type:"POST", url:"./ajax/new.php", data:{id:a, sid:"{SESSION_ID}", mode:"new"}, dataType:"html", success:function(b){....}})};

Das Coding sowie aufgerufene php-script "new.php" funktioniert ansich tadellos in 99,9% aller Fälle (ist darüber hinaus derselbe Code wie beim normalen Seitenaufruf, bei dem es NIE Einträge gibt), nur gelegentlich (bei ca. 1 von 1000 Ajax-Aufrufen) kommen diese serverseitigen Error-Einträge.

Der Server ist ein netcup-managed Vserver, Apache, Debian, natürlich aktuell

Sagt bloß ihr seid alle so ahnungslos wie ich

Obiges ergänzt sich übrigens sporadisch mit

Handler for (null) returned invalid result code 70007

Irgendjemand eine Ahnung oder einen Dokumentations-Tipp, was die Ursache sein kann?

Hallo zusammen,

da dieses Problem erfahrungsgemäß wohl eher nicht Anbieter- und Produkt-spezifisch ist, stelle ich diese Frage hier:

In den Error-Logs tauchen gelegentlich Error500-Einträge auf:

Handler for (null) returned invalid result code 70014

Dies jedoch nur sehr sporadisch, unregelmäßig, nicht-reproduzierbar und daher schwer zu debuggen. Google gibt nicht viel dazu her, außer dass dies in den meisten Fällen womöglich an client-seitigen Proxies liegt. In meinem konkreten Fall treten diese Fehler auch nur bei client-seitigen AJAX-Calls auf, bei denen ein php-script mit übergebenen Variablen per POST aufgerufen wird.

Hat jemand ähnliche Erfahrungen, Tipps, Ideen, Anregungen oder Vorschläge dazu?