Hi All,

Denne tråd er igangværende at blive en diskussion principielt bringe flere oplysninger fra eksperter om cron job og de tilknyttede fil håndtag.

Så her er spørgsmålet.

Der er absolut en konstant 'n' som det maksimale antal filhandlere tildelingsbeløb til en proces, 'p'.

Vil der være nogen forskel, hvis processen 'p' kører som en forgrund proces eller som en proces, udklækkede af cron daemon; I det maksimale antal fil håndtag, der skal tildelingsbeløb til processen?

I bekræftende fald hvorfor er den forskel, eller stort set hvad er de begrænsninger, der i løbet af den proces, udklækkede af cron daemon til, at en proces, der kører som en forgrund proces, sparkede af fra terminalen?

Tak!

Afhængigt af operativsystemet antallet af filen deskriptorer pr proces er fastsat i kernen påkompileringstidspunktet eller konfigureret med en parameter.

Med hensyn til, hvad der gør enhver proces anderledes til UNIX det ville være begrænset virkelig til følgende ...

1. har det en kontrollerende tilknyttet terminal

2. er det moderselskab død

3. er det dødt, så er det en zombie, og har ingen hukommelse, ingen fil deskriptorer og kun en minimal ind i processen listen.

Der er en anden proces bred detaljer, såsom prioriteret, effektiv bruger osv., men ikke meget, der gør en proces anderledes, selv tilfælde 2 betyder blot erstatte det moderselskab pid med '1 '.

Antallet af filen deskriptorer er usandsynligt at ændre.

Den nøjagtige oplysninger varierer afhængigt af OS. Jeg vil bruge HP-UX som et eksempel. Antallet af mulige fil decriptors er under kontrol af setrlimit (2). (En mindre magtfulde interface, ulimit () er også tilgængelig.) En proces kan ikke have mere fd's end "bløde" grænse. Brug setrlimit (2), kan en proces hæve eller sænke sine bløde grænse. Men en proces kan ikke hæve den bløde grænse over hård grænse. En proces kan sænke den hårde grænse. Kun en root proces kan hæve hård grænse. Kerneparametre definere den oprindelige værdi af de hårde og bløde grænse. Selv root kan ikke hæve den hårde loft over den oprindelige værdi for hård grænse. Kernen paramters:
maxfiles
maxfiles_lim

Jeg har snydt en lille smule ved at udvælge HP-UX som min prøve OS. HP-UX tillader dynamisk rekonfigurering af kernen. Kun root kan omkonfigurere kernen. Men en grundlæggende proces kunne, i teorien, øge maxfiles_lim og derefter hæve hård grænse og derefter relower maxfiles_lim. Ikke alle versioner af Unix give så meget strøm til en rod proces.

Jeg tror ikke, at cron fumler med disse grænser.

Som standard stdin, stdout og stderr er filen deskriptorer åbnes under processen skabelse.
Hvis filen grænsen er 16, for eksempel, så processen har 13 filer deskriptorer at spille med.

I shell-scripts, bruger omdirigering op fil deskriptorer. Når linjen "doing" omdirigeringen er afsluttet filen deskriptor er lukket, dvs: ls *> myfile.txt. Omdirigering af blokke af kode, som en løkke, skal du bruge en fil-deskriptor over mange linjer kode.
Cron job køre uden en TTY, stdin er scriptet.

Jim, betyder det så, der plejer være nogen forskel mellem antallet af filen deskriptorer for forgrunden processen og cron job tildelingsbeløb?

Kølig! Jeg havde en underlig tvivl om, at om der kunne være nogen forskel.

Cleared

Tak til alle!

Tak for svaret.

Men mit spørgsmål er mere relateret til forskellen i fordelingen af filen deskriptorer til de forskellige proces (forgrundsviden fra terminal / bund).