Quelques trucs pour vous sortir du pétrin sous Linux.

C’est Pierre L. qui m’a posé les questions, mais comme j’ai beaucoup écrit, je me suis dit que ça aiderait peut-être plusieurs personnes...

Pierre Lachance a écrit :

 As-tu quelques trucs en cas de plantage de Linux ? Plantage ? Plantage d’un logiciel ? De Linux au complet ???

Si tu n’es pas capable d’ouvrir rien, mais que tu es capable de faire Crtl-Atl-F1 (ou F2, ou F3.... jusqu’à F6), tu atteindras une console. Si tu peux te logguer, à ce moment-là, c’est que ça peut-être KDE ou X qui est gelé.

Une façon facile de redémarrer X (ou kdm, le gestionnaire de démarrage de X pour KDE), c’est de faire Crtl-Alt-Backspace. Sinon, en mode console sous root, killall kdm

La commande killall permet de tuer un programme par son nom (que tu peux voir entre autres en faisant la commande pstree qui donne l’arbre des processus.

"init", c’est le processus 1, c’est lui qui démarre tout. Les autres sont des "enfants" (child) du processus init. Un processus qui travaille va souvent faire des enfants pour pouvoir continuer. Mettons httpd (apache), tu vois dans mon pstree 4*(httpd), il y a donc quatre processus httpd enfants de httpd tout court qui écoutent. Donc, si 5 requêtes arrivent exactement en même temps, y’en a une qui va devoir patienter.... Si je fais killall httpd, je tue httpd et tous ses processus enfants.

Je t’écris dans mozilla, dans mon pstree, je ne vois pas mozilla sous init, puisque mozilla a été démarré par kde. C’est kdeinit qui s’est chargé de le démarrer. Des fois, tu peux prendre Xkill pour tuer un programme, mais il peut arriver que Xkill ne tue que la fenêtre et non le programme. Un killall lenomduprogrammegelé va faire l’affaire. Évidemment, un killall tout court KILL(s) ALL, tue toute....

Tu peux aussi voir les processus en mode graphique, il y a plusieurs utilitaires graphiques, ils sont dans le menu KDE dans "Applications/ surveillance" et là, tu as KSysGuard. Il te permet aussi de voir les processus en arbre, c’est souvent plus utile pour voir qu’est-ce qui gèle.

En mode texte, tu pourrais aussi faire la commande top, qui te donnera les processus. Sauf qu’après il faut que tu tues les processus soit par nom avec killall ou par numéro avec la commande kill 78323 (78323 étant le PID, le numéro du processus).

 Si KDE ne démarre pas ? Si tout gèle ?

KDE, tu peux souvent tuer kdeinit qui peut geler (pcq tu aurais agressivement fermé une ancienne connexion mettons).

Si tout TOUT TOUT gèle (pas moyen de basculer d’une console à l’autre, etc), tu peux toujours tenter d’entrer par ssh, si c’est impossible, c’est que tout est planté, alors tu pèses sur le bouton pour redémarrer et tu espère que tu es en ext3 parce que sinon le "scandisk" peut être long.

 Pour ce qui est de cvs, comment savoir s’il est installé ? Cervisia ??? Qu’est-ce ?

CVS, c’est pour Concurrent Versionning System ou qqchose comme. Si tu as installé les outils de développement, cvs devrait y être. Fait la commande cvs en mode console, si ça te dit command not found, c’est que c’est pas installé. Si c’est le cas, va dans le gestionnaire de paquetages et installe le.

Cervisia est aussi un paquetage qui est dans les outils de développement. C’est un client graphique pour CVS. En fait, CVS, c’est très simple : tu as un serveur CVS et un client CVS.

Le serveur CVS, il peut être où tu veux. Dans notre cas, le serveur CVS sera celui de tuxfamily. CVS est un service, comme apache, proftpd, etc. CVS stocke les fichiers (mettons les fichiers php) source et au fur et à mesure que les gens déposent les fichiers dessus, il fait le suivi des changements dans les fichiers (comme phpwiki).

Il faut un client CVS pour parler au serveur CVS. Cervisia est juste un beau programme graphique qui va par dessus le client CVS.

En CVS, il y a plusieurs modes. Au début, j’ai fait un "import" des fichiers. Autrement dit, j’ai importé le dossier jobinote vers tuxfamily (je sais, le mot import est comme à l’envers, mais ça dépend d’où on se place). On importe qu’une seule fois, pour placer des nouveaux fichiers ou dossiers.

Prenons un moment de travail de quelqu’un. ===========================================

"Sur l’air des dialogues phpdagogiques".... ;-)

Tout le monde étant en vacances, B. (un des collaborateurs de G. et de PL), a décidé de placer ses dernières modifications dans le CVS pour en faire profiter tout le monde. Il "commit" (opération qui consiste à envoyer le fichier modifié au serveur CVS, qui calcule les différences entre le fichier qu’il possède et le fichier qui lui est envoyé) ses fichiers modifiés au serveur CVS.

Auparavant, il a utilisé Cervesia et fait "Actualiser" (update) pour que le serveur CVS lui indique quels sont les fichiers qui sont différents de ceux qu’il possède présentement. C’est très utile pour B., car il n’a pas à "commit"er tout ses fichiers s’il ne les a pas modifiés.

PL veut continuer le travail de B.
 B., envoie-moi un zip de ce que tu as mis sur le serveur CVS, comme ça je pourrai continuer d’améliorer le projet.

B. fit un petit sourire en coin...
 Si tu veux... mais ça te sauverait pas mal de travail d’utiliser la fonction checkout de CVS...

 Checkout ?
 Oui, chaque bout du projet (on les appelle des modules) a un nom. Mettons que tu veux récuperer le jobinote. On a nommé le module "jobinote", alors, tu n’as qu’à faire la commande "cvs $CVSROOT checkout jobinote" et il va aller chercher la dernière mouture des sources du jobinote présente sur le cvs.
 $CVSROOT, c’est une variable ça ?
 Oui oui.... j’ai oublié de te parler de la connexion.
 La connexion ?
 Oui, CVS fonctionne en client-serveur. Il faut donc qu’en tant que client, tu te connectes au serveur CVS pour travailler. $CVSROOT est une variable d’environnement, il faut donc que tu la définisses. Tu vas en mode console et tu tapes export CVSROOT=:pserver:tonnomdutilisateur@cvs.tuxfamily.org :/cvsroot/jobinote
 Alors, je suis connecté à ce moment-là ?
 Non, pas encore, tu as défini le chemin de connexion. Tu peux ensuite utiliser la commande cvs login pour te connecter. Ton mot de passe est ton mot de passe de tuxfamily.
 Donc, tout le monde doit être abonné pour aller chercher la dernière version....

B. commence à réaliser que plus il explique, mieux il comprend le principe...
 Non... oui... Non non non... c’est vrai. Il y a un accès anonyme à CVS qui est possible. Alors, si on remplaçait le nom d’utilisateur par anonymous en n’écrivant pas de mot de passe après la commande login, on pourrait aller faire un checkout (aller chercher) la dernière mouture.
 Ah oui ? C’est très intéressant... mais écoute, on s’éloigne du sujet. Mettons que je l’ai récupéré le module, je le mets où ?
 Où tu veux, mais il ne doit pas y avoir d’autres fichiers pareils. Alors, normalement, tu fais un checkout, et ensuite tu peux travailler sur les sources. Et là, tu peux utiliser Cervisia en faisant "Ouvrir une copie locale" pour ouvrir le dossier que tu viens de récupérer.

PL regardait dans le vide, avec les yeux qui donnent des signes d’un travail intense qui a lieu juste derrière eux...

 ....
 Tu comprends ?
 Oui oui... donc, je me connecte, je "checkout" les sources, je travaille dessus et ensuite quoi ?
 Ensuite, tu peux utiliser Cervisia pour comparer tes sources modifiées avec le CVS, pour ça tu utilises la commande "actualiser" (update) soit sur des dossiers, soit sur des fichers. Il te dira si ton fichier est à jour avec le CVS, ou si ta copie est modifiée localement. Si tu penses que ta contribution est bonne, tu fais un "commit" de tes fichiers.
 Alors, c’est facile, un checkout à chaque fois que je commence à travailler...
 Non ! Au contraire !!! Tu fais le checkout juste une fois. Après ça, tu vas toujours retravailler sur les mêmes sources. Lorsque tu vas te rebrancher, si quelqu’un a changé les sources sur le CVS, après avoir ouvert ta copie locale dans Cervisia, il va te dire si tes sources nécessitent une mise à jour ou pas. Si oui, tu peux alors faire un update qui cette fois-là va fusionner les changements sur tes "vieilles" sources...
 Est-ce qu’on l’essaie au lieu d’en parler ???

B. éclata de rire.
 C’est sûr que ça va être plus facile à comprendre en le faisant...

=============================

 As-tu un bon doc qui explique comment compiler des sources sur notre machine ?

Ça varie d’un programme à l’autre.

En général, tu download le .tar.gz , tu le décompresses qqpart dans ton home en faisant tar zxvf lenomdu.tar.gz Ensuite, tu vas dans le dossier créé, et normalement, c’est *./configure *make *make install

si le programme s’installe à des endroits où tu n’as pas les droits, il se peut que tu doives faire make install en root.

Autre chose, regarde les messages lors de ces opérations, si ça marche pas, ça peut être parce que tu n’as pas les librairies de développement nécessaires d’installées.

Bye... (ouf, c’était long !)