Hi All,

Deze draad gaat een discussie in feite om meer informatie van de deskundigen over cron jobs en het bijbehorende dossier handgrepen.

Dus, hier is de vraag.

Er is zeker een constante 'n' als het maximale aantal van het dossier van de toegekende handvatten om een proces 'p'.

Zal er geen verschil, als p het proces 'is uitgevoerd als een voorgrond proces of als een proces voortgebracht door cron daemon, In het maximale aantal bestanden dat wordt verwerkt worden de toegekende aan het proces?

Zo ja, waarom is het verschil, of eigenlijk wat zijn de beperkingen waar over het proces voortgebracht door de cron daemon die van een proces uitgevoerd als een proces schopte van de voorgrond van de terminal?

Bedankt!

Afhankelijk van het besturingssysteem van het aantal file descriptors per proces is vastgesteld in de kernel op tijdstip of geconfigureerd compileren met een parameter.

In termen van wat elk proces verschilt van UNIX zou echt beperkt tot de volgende ...

1. heeft het een controle-terminal verbonden

2. is het de moedermaatschappij dood

3. is dood, dan is het een zombie en heeft geen geheugen, geen file descriptors en slechts een minimale vermelding in het proces lijst.

Er zijn andere proces breed details, zoals prioriteit, effectieve gebruiker etc, maar niet veel, dat maakt een ander proces, zelfs geval 2 betekent enkel vervanging van het ouder pid met '1 '.

Aantal dossier descriptors is onwaarschijnlijk te veranderen.

De exacte gegevens zijn afhankelijk van OS. Ik zal gebruik maken van HP-UX als voorbeeld. Het aantal mogelijke bestand decriptors is onder de controle van setrlimit (2). (Een minder krachtige interface, ulimit () is ook beschikbaar.) Een proces kan niet meer FD's dan de "zachte" te beperken. Gebruik setrlimit (2), kan een proces verhogen of verlagen de zachte limiet. Maar een proces niet kan verhogen de zachte limiet boven de harde limiet. Een proces kan lager de harde limiet. Alleen een wortel proces kan verhogen de harde limiet. Kernel parameters definiëren de initiële waarde van de harde en zachte beperken. Zelfs root kan niet verhogen van de harde limiet boven de initiële waarde voor de harde limiet. De kernel paramters:
maxfiles
maxfiles_lim

Ik heb een beetje bedrogen door picking HP-UX als mijn monster OS. HP-UX maakt dynamische herconfiguratie van de kernel. Alleen root kan opnieuw configureren van de kernel. Maar een wortel proces zou kunnen, in theorie, te verhogen maxfiles_lim en vervolgens verhogen haar harde limiet en dan relower maxfiles_lim. Niet alle versies van Unix geven dat veel macht om een root proces.

Ik geloof niet dat cron violen met deze beperkingen.

Standaard stdin, stdout en stderr zijn file descriptors geopend tijdens proces van creatie.
Als het bestand limiet is 16, bijvoorbeeld, dan is het proces 13 bestanden descriptoren te spelen.

In de shell scripts, omleiding verbruikt descriptoren bestand. Zodra de lijn 'doen' de omleiding is voltooid is het bestand tem dwz sluiten: ls *> myfile.txt. Omleiden blokken van code, zoals een lus, gebruik van een file descriptor gedurende vele regels code.

for file in `ls /path`
do
     cat $file
done > myfiles.txt

Jim, betekent dat er gewoon het eventuele verschil tussen het aantal van het dossier van descriptoren voor de voorgrond-proces en de toegekende cron jobs?

Koel! Ik had een vreemd twijfel dat de vraag of er sprake zou kunnen eventuele verschillen.

Cleared

Thanks to all!

Bedankt voor het antwoord.

Maar mijn vraag is meer gerelateerd aan het verschil in de toewijzing van de file descriptors aan de verschillende proces (voorgrond van de terminal / achtergrond).