[Vienna-pm] anmerkungen ..

Peter J. Holzer hjp-vienna-pm-list at hjp.at
Mon May 28 10:16:19 PDT 2007


On 2007-05-28 18:53:22 +0200, Bernd Petrovitsch wrote:
> On Mon, 2007-05-28 at 18:29 +0200, Peter J. Holzer wrote:
> > Da ist existiert das Problem, dass der Server nie mehr schrumpft ja
> > meistens nicht: Der Parent-Prozess macht nichts außer accept und fork,
> > und bleibt damit schön klein, die Kindprozesse sterben sobald der Client
> > disconnected und geben damit jeden Speicher, den sie hatten, wieder
> > frei.
> 
> Tatsächlich ist das die einzig mir bekannte Methode, temporären großen
> Speicher wieder loszuwerden (z.B. macht der Daemon genau einmal täglich
> irgendwas speicherfressendes): Vorher fork()en und den Worker-Prozeß
> entsorgen, wenn man ihn nicht mehr braucht bzw. der Worker fertig ist.

Zumindest die einzige Methode, die auf verschiedenen Systemen
zuverlässig funktioniert. Auf Systemen, die die glibc verwenden, werden
größere Speicherbereiche (default: ab 128 kB) mittels mmap statt sbrk
alloziert und beim free auch wieder freigegeben. Die
malloc-Implementatioen von BSD (und MacOS) scheinen das auch so halten,
die von HP-UX gibt nie was frei, was sie einmal hat (klassische Unix
malloc-Implementation halt). Und Perl verwendet ja nicht
notwendigerweise malloc/free von der libc, sondern kann auch seine
eigene Implementation verwenden (die meines Wissens auch nie mehr was
hergibt), und wenn das nicht kompliziert genug ist, dann kommen noch die
Geheimnisse des Perl-Memory-Managements dazu, bei dem auch nie so ganz
klar ist, wann es free aufruft, und wann es der Meinung ist, dass es den
Speicherbereich vielleicht sicherheitshalber behalten sollte.

> > Speicher fressen. Mit der "externe-Programme mittels system starten, um
> > die Arbeit zu machen"-Methode hast Du aber genau die verschachtelten
> > forks: Zuerst forkt der Server, wenn er eine neue Connection erhält,
> > dann forkt das Kind für jeden File-Request, und das Enkelkind exect dann
> > cat bzw. zip (und wenn Du nicht aufpasst, hast Du eine Shell auch noch
> > dazwischen).
> 
> Wenn das perl system() intern das libc system(3) aufruft, wird man das
> gar nicht verhindern können.

Tut es nur dann, wenn 

1) es mit nur einem Parameter aufgerufen wird und 
2) dieser eine Parameter "Shell-Metacharacters" (wie auch immer die
   jetzt genau definiert sind) enthält.

Normalerweise kann man das leicht vermeiden und Perl system macht dann
nur ein fork und ein exec. (Darum habe ich "wenn Du nicht aufpasst"
geschrieben)

	hp

-- 
   _  | Peter J. Holzer    | I know I'd be respectful of a pirate 
|_|_) | Sysadmin WSR       | with an emu on his shoulder.
| |   | hjp at hjp.at         |
__/   | http://www.hjp.at/ |	-- Sam in "Freefall"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.pm.org/pipermail/vienna-pm/attachments/20070528/810826c8/attachment.bin 


More information about the Vienna-pm mailing list