Sicher hab ich das richtig verstanden.
bitte, bitte nicht böse sein, aus Deinem Posting oben war (mir) das nicht ganz ersichtlich bzw. ich habe es wahrscheinlich total mißverstanden (mir war z.B. nicht ganz klar, welches Verhalten zu welchem Zeitpunkt Du eigentlich erwartest)... Sollte ich Dich verletzt haben, so bitte ich um Entschuldigung
Der Prozess wird nicht gestartet, heißt, das er bei Anfragen aus dem Netz nicht gestartet wird.
Wie hat sich das Ganze dabei am Client geäußert? Gab's eine Fehlermeldung, wenn ja welche? Stieg Client mit timeout aus? Denn bei mir (mittlerweile) gab's am Client die folgende Fehlermeldung
Code:
svn: Can't find a temporary directory: Internal error
der Prozess auf der Box wurde aber definitiv gestartet - die Fehlermeldung kommt auch von ihm.
Das Ändern auf root, bring den Erfolg. Was spricht dagegen?
Naja, die üblichen Gründe so wenig wie möglich Dienste mit root-Rechten laufen zu lassen (auch wenn Du der einzige User bist und den Port gar nicht nach Außen frei gibst). Außerdem wäre es ein Workaround, besser wäre es das Problem zu verstehen und die eigentliche Ursache zu beheben, was, wie ich meine, mir gelungen ist.
Das Problem besteht darin, dass svnserve (nur im inetd-Modus) es versucht, ein Temp-Verzeichnis anzulegen, was schlicht und ergreifend scheitert, die Fehlermeldung sagt ja auch genau das. Dafür bedient es sich einer Funktion aus der apr-Library, welche wiederum dafür die Verzeichnisse /tmp, /var/tmp, /usr/tmp und noch ein paar andere durchprobiert. Scheitern tut's deswegen, weil der svn-User für keines dieser Verzeichnisse die Schreibrechte hat. Temporäre Lösung
dauerhafte bei mir getestete
Anhang anzeigen fwmod_var_tmp_fixes.patch.txt
@Oliver, Silent-Tears und andere Developer, die vielleicht hier mitlesen: spricht etwas gegen die Aufnahme des Patches in trunk?
Das Verhalten bei manuellen eintragen in die /etc/inetd.conf über das WebIF besteht wie beschrieben. Dort startet der Prozess auch ohne Anfragen aus dem Netz. Ist allerdings nicht so von Bedeutung.
Konnte ich bei mir leider nicht reproduzieren. Das --daemon in der Ausgabe von ps (Punkt 2 aus Deinem Posting) deutet daraufhin, dass der Prozess über rc.subversion gestartet wurde und nicht von inetd (in diesem Fall müsste -i in der Ausgabe auftauchen) - vielleicht hast Du nur vergessen, nach dem Umstellen auf manuell, den Dienst zu beenden oder dieser aus irgendwelchen anderen Gründen nicht beendet werden konnte, das wäre dann aber ein komplett anderes Problem.