Re: Init Panic, j'ai perdu l'heure...
Le Thu, Jun 03, 1999 at 06:47:30AM +0200, Fabrice Gautier écrivait:
> Suite à un joli, plantage de la mort qui tue qui ma obligé à prononcer des
> incantations magiques, debian se comporte comme si l'heure systeme était GMT
> alors que avant elle était à l'heure locale. Comment est-ce qu'on fait pour
> revenir à ca?? Je croyais que tzconfig faisait ca mais apparement non...
> j'ai pas trouve avec date non plus...
Si vous aviez lu la page de manuel de tzconfig vous auriez su :
A WORD OF WARNING
What timezone is correct for your system? It depends on
the geographical location of the machine. Getting the
correct location is important, but the system must also
know how your hardware clock is set. Most DOS based PCs
set their hardware clock on Local Time, while most UNIX
systems set their hardware clock to UTC.
The Debian GNU/Linux system gains its knowledge of this
setting from the file /etc/default/rcS. This file con
tains either the line GMT="-u", which indicates that the
hardware clock is set to UTC, or it contains the line
GMT="", which declares the hardware clock is set to Local
Time. If these setting are correct, and the hardware clock
is truely set as indicated, then configuring the proper
timezone for the machine will cause the proper date and
time to be displayed. If these are not set correctly, the
the reported time will be quite incorrect. See hwclock(8)
for more details on this topic.
> Tout ca pour dire que je pensais pas qu'on pouvait planter aussi facilement
> un système linux (même si apparemment c'est pas le noyo qui fait tout planter
> mais init) juste avec ce petit programme, executer en simple user de surcroit
> (en root j'ose pas imaginer).
Il existe des moyens pour interdire à un utilisateur de consommer plus
de X Mo de mémoire. cf /etc/limits
Mais c'est pas génial, cela ne marche que pour les sessions telnet et
pas pour les sessions XDM.
Il existe d'autres attaques comme celle de remplir la table de processus
(genre while(1) fork;). On se protège de la même manière.
> N'y-a-til pas des options pour limiter la memoire utiliser pas les user simple
> pour que les processus important en ait toujours suffisament en reserve???
> Est-ce que c'est spécifique au noyo, ou est-ce que ca peut dépendre des
> distributions??
Soit bash (cf ulimit) soit le processus parent (comme login) qui impose
ses limites à ses processus fils.
Je trouve que c'est une partie de Linux assez mal faite et pas très au
point. Mais il existe peut-être des outils mieux, on verra bien avec
les autres réponses de ce thread.
> (J'avais deja obtenu un effet semblable sur une station Sun avec un truc du
> genre while(1) fork() sauf que les conséquences étaient moins graves
> et qu'un simple reboot depuis une machine distante avait réussi a eclaircir
> la situation)
Les erreurs sur le disque que vous avez eu ne sont pas systématiques, cela
arrive après certains reboots, très rarement.
> Ou alors est-ce que un super administrateur aurait put se tirer de cette
> situation mieux que moi?
Il vaut mieux prévenir que gérir mais oui on peut réparer.
Le tout est de travailler sans lancer de nouveaux processus (qui
impliquerait de nouveaux appels à malloc voués aux échec), donc il faut
un shell (root de préférence, mais celui de l'utilisateur qui cause les
dégats devrait aussi aller) et se servir des fonctions 'builtins' pour
faire le ménage. Pour trouver les processus et essayer d'identifier le
coupable on se promène dans /proc (cd, read, echo sont des builtins, cf
man bash pour la liste complète), ensuite on kille le processus (kill
est aussi un builtin, je ne sais plus comment on force le choix entre
l'éxécutable et le builtin).
Amicalement.
--
Hertzog Raphaël >> 0C4CABF1 >> http://prope.insa-lyon.fr/~rhertzog/
Reply to: