Reprise du message précédent :

 
pose ta question

et bien ça marche pas

j'essaie en radius et en tacacs+, mais je ne sais pas du tout où peut se situer le pb vu la verbosité des log : % Authentication failed.  
je suis la doc cisco mais elle n'est pas très parlante finalement

j'ai un serveur cisco ACS, j'ai un groupe avec 3 users dedans
j'ai défini mon switch dans le serveur, avec auth tacacs+
je configure en regard sur le switch :

je défini mon serveur radius/tacacs (IP, key, ...)
et enfin :

mais ça marche pas

Bonjour !
 

 
un TT ?  

accordé

putaing, hier, j'ai un process mplayer qui refusait les kill -9 !  
ça arrive souvent

j'utilise ça :

(avec en plus un user local en backup)

par contre mon serveur tacacs+ c'est pas du ciscal, c'est tac_plus -> http://www.shrubbery.net/tac_plus/

"local" à droite ça veut dire d'essayer l'auth local en plus de tacacs ?
c'est pas ce que je comprends en lisant la doc

t'as essayé de le faire en root ton kill ?
sinon, ça arrive parfois que certains process mplayer zombie soit récalcitrants et mettent du temps à se décomposer, généralement quand tu as un souci I/O sur un cd ou un dvd

de toute façon tant que j'aurais ça ça risque pas de marcher je pense

Bonjour
 

 
A chaque fois qu'un processus sera dans un niveau de priorité trop haut pour les signaux, et donc non "interruptible" par un signal.
 
Généralement, c'est le cas pour les opérations de swap (page in/page out), les opérations d'I/O (genre DMA), ou le VFS (essayer de killer un processus locké sur un stat() sur un montage NFS avec le serveur HS, par exemple).

question bete, alors comment le process est killé lors d'un shutdown ou d'un reboot ?

je sais qu'un "fuser -k /dev/bla" permet de killer le process qui "retient" le device "bla", mais je suis pas certain que ça soit ce qui est utilisé lors d'un shutdown en fait
 
Sinon je crois bien que c'est SIGKILL pour tout le monde épicétou  

il est détruit salement

 
dans ces cas là, il faut esperer pouvoir reussir à s'en sortir avec un 'nice', mais il est generalement trop tard

fuser -k j'ai dit

bon ça va
tu es tout pardonné
 

http://www.lemonde.fr/carnet/artic [...] id=1041090

j'ai entendu ça ce matin à la radio oué
le superbanco saÿtaÿmieuhavan

en fait tu es vieux

Ouais, il a connu les francs

 
OMG  

moi aussi

Les anciens tu veux dire ?!  ²

J'ai gagné mon match de pétanque. On les a éclaté

"Les booléens" ?

Suivant la configuration et le caractère gentil ou non de la chose, ca va du simple "j'attends que le processus sorte du kernel land et ensuite je le tue", à "je le dégage de la queue manu militari (ca revient à le sched_dequeue + dégager les ressources qui lui sont allouées)". Le shutdown/reboot se fait en kernel land. Les signaux c'est purement userland, le noyau peut tout à fait dégager n'importe quel processus quand il veut en désallouant les ressources associés et en libérant sa place dans la queue.

A charge au noyau de bien flusher les buffers et les caches éventuellement, pour garder un FS cohérent par exemple (surtout si le processus était en état bio).

Y'a aussi une autre possibilité, appeler le debugger du kernel et dégager le processus à la main. A ne faire que via une console, n'essayez surtout pas ca en passant par ssh ou vnc...

Aucune chance, si c'est un processus en uninterruptable sleep, le processus tourne déjà dans le kernel land, et il _dort_ (il est dans la sleep_queue), en attente d'une ressource matérielle, qui peut ne jamais arriver. Dans tous les cas, le scheduler a déjà fait son boulot, vu qu'il a dégagé le processus en question pour laisser la place aux autres;

à coup de boules ?
tu m'étonnes
 

 
c'est surtout ça le défi

 
Oui
 
Le rajout du support SMP et threads de feu de dieu dans les BSD a fait des discussions trèèès chiadées entre les dev. C'est hautement pas trivial avec plusieurs CPU, plusieurs threads qui peuvent être dans le noyau et des CPU qui n'ont pas forcément les mêmes tables d'interruptions, qu'est ce qu'on a mangé sur les versions -current en deux ans

Non, les "raboule ta fraise".
 
Spa moi qui ai choisi

http://forum.hardware.fr/hfr/OSAlt [...] _1.htm#bas
 
Tomate, sors de ce corps

 
 
j'suis sur qu'il a meme pas osé appeler son equipe comme ça

en effet

 
c'est ce qu'on dit ...

 
pour Python
 

P'tain, y'a le collègue qui s'occupe de l'entretien du batiment qui essaye de nous asphyxier là
Il est en train de faire chépakoi, mais alors ça pue le mélange de souffre et de peinture

il a peté
 
/o\

vu l'odeur, vaudrait mieux pas pour ses intestins
ça pue vraiment là
et moi qui ai les yeux fragiles, j'en ai limite les nyeux qui pleurent