Zuerst habe ich geglaubt es wäre ein Prefork, da bjoern/lightweight aber über eine eventloop fährt braucht pyLoad sicher keine für die HTTP Interfaces. Das ARM Paket kommt mit einem pyLoadCore.py Prozess aus.
Das x86 Paket zeigt mir dagegen in der Prozessliste stets 12 Forks (inhaltlich praktisch gleich unter /proc), die nicht besonders aktiv sind, in pyLoad selbst sehe ich nur Forks für Captchas und UnRAR...
Sicher ist: Es findet relativ bald nach der Dämonisierung statt.
Das aktuelle x86 Paket (-4) hat bis jetzt zumindest einen mir bekannten, bislang unkritischen Fehler: pyLoad findet seine eigene Instanz nicht (immer). Deshalb führt "pyLoadCore.py -q" in
start-stop-status nie zu etwas und der Daemon wird per sigkill gestoppt. Dabei sieht es so aus als hätte pyLoad keinen Signal Handler was zum default führt: Sofortiges Prozessende. Als Anwender merkt man es daran, dass Änderungen des Admin Passworts in der pyLoad Web GUI (die pyLoad soweit ich es bisher sehe erst beim sauberen -q dauerhaft ablegen würde) bei einem Paketrestart verloren gehen. Es gibt Work-arounds mit dem Script, der Fehler ist da und ist ein Fehler des Pakets, nicht von pyLoad selbst - jedenfalls nach aktuellem Erkenntnisstand
Wo er stört ist die Frage, deshalb der kurze Ausflug, meine aktuelle Vermutung ist ein Zusammenhang zu diesen untätigen Schwesterprozessen.
Ist also auch bei mir ein noch offenes Thema, sie stören nicht und brauchen als Forks ihren RAM laut
htop und Co auch nicht exklusiv, keine Sorge
, aber schön sind sie nicht.
Freue mich über investigative Erkenntnisse - sind es bei dir auch 12 oder schwanken sie sie je nach Nutzung irgendwann (bei mir nie)?
