Vous êtes sur la page 1sur 13

Gestion De Processus sous UNIX

Introduction
Unix est un système d'exploiration multi-tâche et multi-utilisateurs, ce qui veut dire
d'une part que plusieurs individus peuvent accéder aux ressources de l'ordinateur en
même temps et d'autre part que plusieurs programmes peuvent s'exécuter en même
temps.

En même temps ? non, pas tout à fait ... En effet, de nous jours, la majorité des
ordinateurs ne compte encore qu'un seul processeur, lequel n'est capable d'exécuter
qu'une seule instruction à un instant précis. Si nous désirons lancer plusieurs
programmes en même temps, (nous parlerons ici de processus), ces derniers
accèderont chacun à leur tour aux ressources de la machine. Une telle politique est
dite de time sharing (partage du temps).

Bien entendu, un tel système n'est pas simple à gérer. En effet, il faut prévoir un
partage équitable des ressources entre les divers utilisateurs, de manière, par
exemple, à favoriser les processus interactif (ceux qui communiquent et
interagissent directement avec l'utilisateur, comme, par exemple, un éditeur de
texte, ou un programme de dessin vectoriel) au détriment des programmes de
calcul batch.

Trois processus particuliers


Certains programmes sont privilégiés dans leur accès aux ressources par rapport
aux autres. Ce sont des programmes du système assurant son bon fonctionnement.
Nous ne parlerons ici que de trois d'entre eux tout particulièrement importants :

Le scheduler
Il est précisément charger de l'affectation du processeur aux différents
processus actifs. Ces derniers sont rangés dans une liste où chacun se voit
attribué une priorité. Lorsque le processus courant est « viré » du processeur,
le prochain processus à disposer du processeur est celui dont la propriété est
la plus faible dans la liste. Cette même priorité détermine également du laps
de temps accordé au processus.
Une fois son temps passé, le processus est réintroduit dans la liste avec une
priorité très élevée. La réévaluation des priorités des différents processus suit
des règles compliquées qu'il serait superfétatoire d'expliciter ici.
Pour en terminer avec le scheduler, celui-ci a donc à charge de gérer les
priorités, affecter les ressources au processus etc. Il est évident que sa
priorité personnelle est toujours très basse afin qu'il puisse exécuter
correctement sa tâche.
Le syncer
Autre processus particulièrement important, le syncer est chargé de
l'actualisation des informations contenues sur les disques, en particulier le
vidage des buffers du système vers les fichiers ainsi que la mise à jour des
répertoires.
En particulier, il est hyper important d'activer le syncer avant d'arrêter le
système, sinon, les partitions ne sont pas stables.
Le swapper
Traditionnellement moins connu que ses deux prédécesseurs, le swapper n'en
revêt pas moins une importance cruciale : sauvergarder sur disque certaines
pages mémoires momentanément retirées de la mémoire centrale (on dit
qu'elles sont swappées) et rechercher sur le disque les pages mémoire
swappées lorsque le besoin s'en fait sentir.
Pourquoi un tel mécanisme ? me demanderez vous. Supposons que nous
ayons au moins 2 processus actifs nécessitant 220Mo de mémoire pour
s'exécuter et que votre machine ne dispose que de 256Mo de mémoire
centrale. Lorsque l'un des deux devient le processus courant, il va avoir
besoin de toutes les ressources de la machine, aussi, le code exécutable des
autres, ainsi que leur données, vont être momentanément basculées sur le
disque afin de libérer de l'espace. Lorsque ces programmes seront réactivés,
leur état sera reconstruit d'après les informations stockées sur le disque.
Le mécanisme de swap repose sur la notion de page mémoire. Une page est
une unité élémentaire de mémoire pour l'opération de swap. Lorsqu'un
processus demande à accèder à une adresse mémoire, le système commence
par vérifier si celle-ci est présente en mémoire. Si oui, le processus y accède
immédiatement, sinon, il reçoit un signal page-fault, lui intimant de
s'interrompre. Le swapper charge alors la page requise avant d'envoyer un
signal page-ready au processus afin que celui-ci puisse reprendre son
exécution.

La gestion des processus


Les Caractéristiques D’un Processus
Comme nous le verrons dans une prochaine section, tous les processus sont lancés
par le même schéma de duplication / recouvrement. De ce fait, chaque processus a
un père : le processus qui l'a lancé. Chaque processus ? pas tout à fait, il en est un
qui déroge à la règle, tout simplement par ce qu'il est le premier à être lancé et qu'il
sera également responsable de l'arrêt du système. Ce processus si particulier
s'appelle init, comme il est le premier à apparaître sur le système, son PID est égal
à 1.
Le tableau suivant résume les principales caractéristiques d'un processus Unix.
Certaines d'entre elles peuvent manquer dans certaines versions un peu ésotériques
d'Unix (SCO, par exemple), alors que d'autres versions en ajouteront.

Identificateur numérique unique de chaque processus. Ils sont affectés


par le système en ordre croissant. Lorsque l'on arrive en bout de plage,
PID
on recommence à 2 en prenant bien soin de ne pas réaffecter un numéro
déjà présent
PID du père du processus. Par défaut, tous les processus ont un père. Il
n'existe que 2 exceptions :

PPID • le processus init qui est le premier lancé

• les orphelins, c'est à dire les processus dont le père est mort. Ils
sont le plus souvent récupérés par init
Le mode d'exécution est représentatif de l'état du processus, plusieurs
modes sont possibles :
Le processus est actif et exécute des instructions de
R Running
type utilisateur
Ce processus est mort, mais son père est encore actif
et n'a pas effectué d'instruction wait ou waitpid
Z Zombie
Un processus Zombie n'occupe pas de ressources
systèmes mais « spame » la table des processus
Processus en attente d'une ressource (fichier, page
Mode W Waiting
mémoire, sémaphore etc...)
d'exécution
En cours de mort, le plus souvent, ce genre de
D Dying
processus est en train d'écrire un fichier core
Ce processus est actuellement inactif et « swappé »
sur le disque. Ce qui signifie littéralement que tout
S Swapped son code d'exécution et son espace d'adressage ont
été renvoyés sur disque. Lorsqu'il deviendra actif,
son état sera restauré à partir du fichier de swap.
Le processus a été stoppé par l'envoi du signal stop,
S Stopped
par exemple par la frappe du contrôle CTRL-Z
Taille La taille mémoire d'un processus est composée de 2 grands éléments :
mémoire la taille statique et la taille dynamique.
La taille statique est liée à l'éxécutable au moment de son lancement,
elle comprend :

• la taille du code lié statiquement


• les données statiques
• la pile initiale

La taille dynamique est plus complexe à définir, toutefois, on peut


énumérer les grandes composantes suivantes :
• la taille du code lié dynamiquement
• Les augmentations de taille de pile si celle ci est dynamique
• Les données allouées dynamiquement sur le tas

Comme nous le verrons dans les exemples liés à la commande ps, BSD
et System V ont des manières différentes de calculer la taille mémoire
d'un processus.
Priorité Conditionne l'affectation de la CPU aux processus.
L'utilisateur a la possibilité d'influencer la priorité de l'un de ces
processus gràce au nombre de nice. Qu'est ce que cela signifie en
clair ? Supposez que vous lanciez un gros programme de calcul non
interactif dont vous n'attendez pas le résultat avant le lendemain. Plutôt
que de lui accorder la priorité normale, vous décidez d'être sympa avec
Nice les autres utilisateurs (être nice en Rosbif) et vous lui donnez une
priorité inférieure gràce à l'ordre nice.
Certains administrateurs système obligent leurs utilisateurs à
déclarer nice tout processus de calcul nécessitant plus de n secondes
pour s'exécuter afin de laisser la priorité aux utilisateurs effectuant du
traitement de texte ou de la compilation.
Il y a trois «durées d'exécution différentes pour un processus »
LA DURÉE « WALL CLOCK »
Littéralement « durée écoulée à la pendule » elle mesure
l'intervalle séparant la date de lancement du processus de
l'heure courante. Bien entendu, sur un système multi-processus,
cela ne veut pas dire grand chose.
LA DURÉE « UTILISATEUR »
La durée utilisateur correspond au nombre de millisecondes
affectées à votre processus sur la CPU pour l'exécution
d'instructions utilisateur, c'est à dire de toute instruction non
privilégiée (voir ci-dessous)
La durée « système »
La durée « système » correspond au nombre de millisecondes
Temps CPU
affectées à votre processus sur la CPU pour l'exécution
d'instructions systèmes ou privilégiées. Ces instructions font
partie du noyau du système. Elle concernent tous les appels
système de bas niveau, tel que l'écriture physique sur le disque
etc.
La principale caractéristique des primitives du système est
d'être non interruptible. En d'autres termes, une fois une
primitive système lancée : aucun signal ne pourra venir
l'interrompre, le processeur reste acquis pour le processus
courant jusqu'à la fin de la primitive.

On peut considérer que la durée CPU totale est la somme de la durée


utilisateur et de la durée système.
Date de Spécifie la date de l'heure de lancement d'un processus. Bien que la
lancement commande who indique depuis combien de temps, le système est
« debout », cette information peut être obtenue en regardant la date de
lancement du processus init.
Chacune de ces informations est donnée selon deux modalités : réel et
effectif. Ainsi, le propriétaire réel est le nom de login de l'utilisateur qui
a lancé la commande. Idem pour son groupe.
Le propriétaire effectif (respectivement, le groupe effectif) est
Propriétaire
identique au propriétaire réel (respectivement, le groupe réel), à moins
et groupe
que l'exécutable de la commande ne soit doté du
flag setuid (respectivement setgid), auquel cas le propriétaire effectif
(respectivement, le groupe effectif) devient le propriétaire
(respectivement le groupe) du fichier exécutable.
Répertoire de
Habituellement, le répertoire à partir duquel a été lancé la commande
travail
Indique le nom du répertoire à partir duquel a été lancée une
commande. Aucun terminal n'est affecté à une commande lancée en
Terminal de
mode asynchrone. De même, si vous avez lancé une commande en
contrôle
mode no hangup puis tué le terminal de lancement, cette information
n'est pas disponible car sans intérêt.

La commande ps
Cette commande fondamentale permet d'obtenir la majorité des informations sur les
processus actifs sur le système ... à condition d'activer les bonnes options ! Par
défaut, elle n'affiche que très peu d'informations relativement aux processus lancés
sur le terminal courant, tout son interet réside dans les très nombreuses options dont
elle dispose. Malheureusement, ces options varient énormément d'une version à
l'autre.

Lorsque l'affichage long est activé, nous aurons, en particulier, les renseignements
suivants :

• Date de lancement
• Taille du processus
• Ligne de commande
• Propriétaire
• PID
• Priorité, etc ...

Syntaxe System V :

-e Tous les processus


-f Version longue, à combiner avec -l
-l Autre version longue, à combiner avec -f
-u uid | Affiche les processus de l'utilisateur spécifié, soit pat
nom son identificateur numerique uid soit par son nom
Question : Sous System V, il est bon de se faire une commande permettant de
récupérer l'ensemble de ces processus, saurez vous la réaliser de manière simple ?
(solution). Les options -f et -l permettent toutes les deux d'avoir un affichage long,
en fait elles diffèrent principalement sur le format d'affichage du temps CPU. La
combinaison des deux offre un affichage très complet.

Syntaxe BSD

Personnellement, c'est ma préférée :)

-a
Tous les processus attachés à un terminal de
contrôle
-u Version longue
-uw
Version très longue ! en particulier, la ligne de
commande complète est fournie
-x
Affiche les processus qui n'ont pas de terminal de
contrôle

Par rapport à la version System V, la version BSD offre, à mon avis, une meilleure
présentation des choses.

Question : Saurez vous écrire, une commande permettant de lister tous vos
processus ? si vous avez déjà répondu à cette question pour System V, cela ne
devrait pas pous poser de problème particulier. (solution)

Un petit mot pour les utilisateurs d'AIX

Les versions récentes d'AIX sont plutôt de type System V. Toutefois, les gens de
chez IBM ont compris que la syntaxe BSD de la commande ps était préférable à la
syntaxe System V. Aussi, ils ont équipé leur commandeps du double jeu d'options.
Pour utiliser les options System V, il faut les préfixer d'un -alors que les options
BDS s'utilisent nues. Attention à ne pas vous emmeler les baskets, en particulier
avec l'option -u/u qui ne veut pas du tout dire la même chose dans les deux cas !

En outre, il ne faut pas se leurrer, même si AIX propose la syntaxe BSD, il n'en
deumeure pas moins un système de type System V. Aussi, certaines informations
fournies par BSD seul seront toujours absentes

Exemple d'exécution de ps

Nous donnons ici un exemple d'utilisation de ps sur un ordinateur AIX en utilisant


les 2 syntaxes. Ne perdez toutefois pas de vue que le ps BDS n'est qu'émulé par
celui, natif sous AIX, de System V.

Syntaxe et présentation BSD


Commande : ps ux

USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND
bruno 20922 0.0 0.0 140 336 pts/5 A 12:41:06 0:00 -bin/csh
bruno 22492 0.0 0.0 140 240 pts/4 A 12:43:06 0:00 ps ux
bruno 24196 0.0 0.0 488 864 - A 12:41:01 0:00 /usr/bin/X11/aixi
bruno 28596 0.0 0.0 728 1004 - A 12:41:05 0:00 /usr/dt/bin/dtter
bruno 30062 0.0 0.0 556 916 - A 12:41:00 0:00 /usr/dt/bin/dtses
bruno 29872 0.4 0.0 1496 2292 - A 12:41:02 0:01 dtwm
bruno 29618 0.0 0.0 1072 1428 - A 12:41:05 0:00 /usr/bin/X11/xter
bruno 27320 0.0 0.0 140 344 pts/4 A 12:41:06 0:00 -sh
bruno 26786 0.0 0.0 368 824 - A 12:41:01 0:00 /usr/dt/bin/ttses
bruno 7130 41.7 0.0 28 36 - A 2:43:00 0:00 ./boucle

Syntaxe et présentation SystemV

Commande: ps -lf -u `whoami`

F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD
200001 A bruno 7024 27320 0 60 20 1f4fa 368 15:04:58 pts/4 0:00 xterm
240001 A bruno 20922 28596 0 60 20 cacc 156 5b4de44 12:41:06 pts/5 0:00 /bin/c
200001 A bruno 22136 27320 0 60 20 12471 340 15:05:16 pts/4 0:00 xterm
240001 A bruno 24196 30062 0 60 20 17ede 500 12:41:01 - 0:00 /usr/bin
240001 A bruno 25202 7024 1 60 20 5963 140 15:04:58 pts/6 0:00 -sh
200001 A bruno 26320 25202 10 65 20 177bf 180 15:05:53 pts/6 0:00 ps -lf -
240001 A bruno 26786 1 0 60 20 1c535 380 12:41:01 - 0:00 /usr/dt/
240001 A bruno 27320 29618 0 60 20 d2ec 156 5a88844 12:41:06 pts/4 0:00 -sh
240001 A bruno 27514 22136 0 60 20 10234 140 5afc444 15:05:17 pts/8 0:00 -sh
200001 A bruno 27786 27514 92 125 39 15156 28 15:05:32 pts/8 0:20 ./boucle
240001 A bruno 28596 30062 0 60 20 7c6 744 12:41:05 - 0:00 /usr/dt/
240001 A bruno 29618 30062 0 60 20 3ce7 1088 12:41:05 - 0:00 /usr/bin
240401 A bruno 29872 30062 0 60 20 1dddd 1520 12:41:02 - 0:01 dtwm
240001 A bruno 30062 29262 0 60 20 1bbba 568 12:41:00 - 0:00 /usr/dt/

De toute évidence, les informations présentées dans les deux cas sont totalement
différentes ! En outre, vous remarquerez que la gestion de la taille des processus
n'est pas la même dans les deux cas. Donnons tout de suite quelques explications
quand à certaines informations données par System V et non présentes sous BSD.

WCHAN
Comme nous allons le voir dans une prochaine section, il est possible de
communiquer avec un processus en lui envoyant des signaux. Lorsque cette
rubrique est renseignée, cela veut dire que le processus est bloqué en attente
d'un signal à l'adresse WCHAN. Il attend donc un signal libérateur pour
reprendre son exécution.
PRI
Vous vous en doutez, c'est la priorité courante du processus
NI
Nombre de nice du processus

Permettez moi encore d'insister sur le fait que la présentation de ps en mode BSD
précédente est soumis à caution car elle a été effectuée sur un système System V
émulant BSD. Tous les administrateurs système chevronnés vous le diront, la
commande ps de BSD est nettement supérieure à celle de System V.

Un petit mot sur les systèmes utilisant la partition /proc

Les processus étant reliés entre eux par des relations père / fils, il semble naturel de
les représenter par une structure arborescente, aussi certains systèmes ont ils
transposé cette organisation sous forme d'une arboresence de répertoires enracinée
dans une partition spéciale (et en mémoire) nommée /proc.

A chaque niveau de l'arborescence, on retrouve des fichiers significatifs du


processus courant ainsi que des sous répertoires représentatifs des processus fils.

Cette organisation est très intéressante car elle évite aux commandes orientées
processus telles que ps ou top d'aller fourrer leurs sales pattes dans le /dev/kmem.
Toutefois, elle ouvre des brêches de sécurité non négligeables.

A l'heure actuelle, le /proc est fourni par défaut sur certaines implémentations de
Linux et en option pour Solaris.

Les mécanismes de Job-Control


Introduction
A la suite de csh, tous les interpréteurs de commandes modernes ont proposé des
mécanismes permettant à un utilisateur de gérer aisément les différents processus
lancés depuis un même terminal de contrôle. Les mécanismes proposés vont
permettre :

• de connaître la liste et l'état des processus lancés depuis un terminal, l'état


pourra être :
o actif en tâche de fond
o stoppé
• Stopper un processus s'exécutant au premier plan
• ramener au premier plan un processus qui s'exécute en arrière plan (tâche de
fond) ou même stoppé
• exécuter en arrière plan un processus stoppé

En guise de préliminaire, rappelons qu'une commande est dite au premier plan si


elle reçoit les événements du clavier. Tant que le processus au premier plan n'est
pas terminé, il est impossible d'en lancer un autre depuis le même terminal.

Par défaut, lorsque vous lancez un processus, il s'installe au premier plan, toutefois,
il est possible de lancer une commande en arrière plan en la faisant suivre du
symbole et commercial &.

Les commandes du job control


La commande jobs

Elle permet de connaître la liste et l'état des divers processus attachés à votre
terminal. Utilisée avec l'option -l, elle vous fournira également le PID de chaque
processus.

Chaque processus est associé à un numéro d'ordre. Il est possible d'utiliser ce


numéro, précédé du signe % avec les autres commandes du job control, et même la
commande kill. Le processus courant est repéré par la lettre +. Toute commande
de job control exécutée sans argument lui est directement appliqué.

Lorsque l'on lance un nouveau processus en tâche de fond, ou que l'on stoppe le
processus de premier plan avec ^Z, ce processus devient le nouveau processus
courant. Sous certains systèmes, il est également nanti du numéro 1, les autres
processus voyant leur numéro augmenter.

La commande fg

Cette commande permet de relancer un processus stoppé au premier plan ou bien


de ramener au premier plan un processus s'exécutant en arrière plan.

Elle peut s'utiliser avec pour argument :

• Le PID d'un processus


• Le signe % suivi du numéro d'ordre d'un processus tel que renvoyé par la
commande jobs
• Sans argument, auquel cas, elle s'applique au processus courant (celui dénoté
par + dans la liste fournie par jobs)
La commande bg

Elle permet de relancer en arrière plan un processus stoppé. Elle prend les mêmes
arguments que son homologue fg.

Commande associée

La commande kill est souvent associée au job control car elle permet d'envoyer
des signaux, c'est à dire des messages de commande aux processus. En outre, elle
reconnaît la syntaxe %n permettant de spécifier un processus par son numéro
d'ordre dans le job control.

Une session complète d'utilisation du job control


L'exemple suivant est typique d'une session de travail avec le job control.
bipro: jobs -l
[1] + 25908 Running ./boucle
bipro: xterm &
[1] 27692
bipro: jobs -l
[1] + 27692 Running xterm
[2] 25908 Running ./boucle
bipro: fg %2
./boucle ^Z
Suspended
bipro: jobs -l
[1] - 27692 Running xterm
[2] + 25908 Suspended ./boucle
bipro: bg %2
[2] ./boucle &
bipro: jobs -l
[1] + 27692 Running xterm
[2] 25908 Running ./boucle
bipro: kill %2
bipro:
[2] Terminated ./boucle

Etudions cas par cas ces différentes lignes ...

1. Au début, nous avons un seul processus dabs ke job control, son statut
est Running et sa ligne de commande ./boucle
2. On lance ensuite un processus xterm en arrière plan (avec le caractère et
commercial &). Le système nous renvoie alors son numéro d'ordre (ou,
numéro de job) et son PID. L'exécution de la commande jobs -lnous
confirme bien cet état de fait.
3. Ensuite, nous ramenons au premier plan le processus de numéro de job 2 par
la commande fg %2. Le système nous rappelle alors sa ligne de
commande ./boucle avant de lui donner la main. A ce moment la, le
programme boucle est au premier plan. Nous le stoppons alors avec la
combinaison de touches ^Z ce qui amène le message Suspended. L'exécution
de jobs -l nous confirme cet état de fait.
4. Ce processus est alors envoyé au second plan avec la commande bg %2, ce
qui amène le système à nous afficher son numéro de job et sa ligne de
commande. L'exécution nous est confirmée par le résultat de la
commande jobs -l
5. Finalement, nous utilisons la commande kill pour tuer le processus. Notez
que cette commande reconnaît la syntaxe %n pour spéficier un processus.

Il est intéressant de noter que le processus courant (dénoté par +) évolue tout au
long de la séquence.

Question (très simple) : Au moment de lancer emacs, vous avez oublié de le


mettre en tâche de fond (comme toute bonne commande X qui se respecte).
Comment allez vous faire pour rectifier le tir ? (solution)

Lancement asynchrone de processus


Introduction
Il est souvent intéressant de vouloir lancer de manière asynchrone un ou plusieurs
processus. Unix nous propose plusieurs commandes permettant de différer
l'exécution d'un programme. Toutes partagent une caractéristique commune : le
traitement de la sortie et de l'entrée standard.

En effet, ici se propose un problème majeur : puisque l'utilisateur ne sera pas


derrière son écran pour surveiller son programme, que doit on faire de la sortie
standard de son programme, et que se passe-t-il si le programme en question attend
des données au clavier ?

Considérons pour commencer le cas de l'entrée standard. La réponse est simple : il


faut faire très attention dès lors que l'on désire lancer de manière asynchrone un
programme susceptible de poser une question au clavier. Deux grands cas peuvent
se produire :

1. L'utilisateur a pris soin de rediriger l'entrée standard depuis un fichier (il faut
alors bien connaître son programme) et tout se passera normalement
2. La première interrogation stoppera le programme car aucun programme en
arrière plan n'est sensé faire d'entrée conversationnelle

Pour ce qui est la sortie standard, le problème est moins grave. En effet, le fait que
la sortie standard ne soit pas consultable directement n'agit pas directement sur le
déroulement du processus.
1. Si l'utilisateur a pris soin de rediriger la sortie standard le fichier indiqué sera
créé
2. Sinon, la sortie standard sera renvoyée par mail

Il faut bien noter qu'un mail sera généré même si la sortie standard est en fait vide !
Si vous ne souhaitez pas recevoir le fameux mail, il vous est possible de rediriger la
sortie standard vers /dev/null.

Notons pour finir que les commandes de lancement asynchrone n'acceptent


habituellement pas que la commande différée ne contienne de redirection (le shell
aurait du mal à savoir à quelle commande est associée ladite redirection). Le plus
simple consiste à créer un script minimaliste contenant la commande et ses
redirection et passer ce dernier à la commande de lancement asynchrone.

Les commandes de lancement asynchrone


Trois formes de lancement asynchrone vont être étudiées

1. Lancement dès que la charge du système le permet


2. Lancement différé une seule fois
3. Lancement répétitif et régulier dans le temps

La commande batch

C'est la plus simple des commandes de lancement asynchrone. En effet, elle permet
d'exécuter son argument dès que la charge du système le permet. Le seuil de charge
dépend du système, mais en général, aucune commande ne sera lancée tant que la
charge de chaque processeur est supérieure à 1.

La commande at

La commande at permet d'exécuter la commande passée en argument à la date et à


l'heure spécifiés. Les options -l et -r permettent respectivement à un utilisateur de
consulter la liste des commandes qu'il a mis en attente et d'en supprimer certaines.

La commande crontab et le démon cron

Le démon cron est vital pour l'administrateur système car il permet de lancer des
commandes à date et heure fixe et ce de façon répétitive. Par exemple, cela vous
permet de lancer tous les soirs à 22h00 une commande de sauvegarde incrémentale
par rapport à la veille et chaque dimanche matin à 10h20 (pendant auto moto :))
une sauvegarde complète.

Le démon cron est en fait très simple. A chacun de ces réveils, il consulte une table
des processus à activer. Si la combinaison date/heure d'activation correspond avec
la date/heure courante, le processus est exécuté. Notez bien que l'exécution du
processus ne le retire absolument pas de la table ! et c'est précisément sur ce fait
que repose l'exécution répétitive.

La commande crontab permet d'ajouter des processus dans la table du démon, de


lister son contenu et d'en retirer certains processus. La syntaxe changeant
énormément d'une version à l'autre, il est bon de consulter l'aide en ligne afin
d'obtenir une confirmation directe.

Solutions des (petites questions)


Commande ps permettant d'afficher tous ses processus
propres (System V)
La commande est la suivante :
ps -lf -u `whoami`

La commande whoami permet de retrouver votre nom de login, donc il est naturel de
passer son résultat à l'option -u de ps.

Cette commande, fort utile au demeurant, peut être mise en alias si vous utilisez
Korn Shell ou Csh.

Commande ps permettant d'afficher tous ses processus


propres (BSD)
La commande est la suivante :
ps -ux

Elle est beaucoup plus simple que son homologue SystemV. Il convient toutefois
de ne pas oublier le -x des processus non attachés à un terminal.

Renvoyer en tâche de fond un processus s'exécutant au


premier plan
La séquence de commandes est très simple. Dans le terminal de lancement, vous
tappez ^Z pour stopper le processus. Celui-ci devient alors le processus par défaut
du job control de votre terminal. Il vous suffit alors de tapper bg pour le réexécuter
en arrière plan.