Merci pour cette nouvelle précision. C'est d'ailleurs ce que j'avais compris (post au dessus du tiens au moment où je frappe ce commentaire).
J'ai commis l'erreur de croire que le fait que le test de l'existence du fichier de vérrou et l'ouverture de ce fichier en écriture soient dans le même bloc entraîne de fait la réalisation de ces deux instructions d'une seule traite, sans interruption.
Je comprend maintenant d'où vient le problème, d'autant plus si c'est pour une page web.
Ok... J'ai cherché et j'ai au moins trouvé ça http://fr.wikipedia.org/wiki/Mutex(...) (si ça peut aider...).
Merci pour l'info, je comprend pourquoi ça ne peut pas marcher...
Si j'ai bien compris ce que j'ai lu et ce que tu as écrit, ça vient du fait que la première partie du test peut être lancée plusieurs fois en même temps, alors que la seconde n'est pas encore effectuée.
Je pensais, lorsque j'ai écrit ces lignes, que le fait que les tests étaient regroupés dans une seule condition rendait ce test atomique (en tout cas, que la main ne serait pas rendue tant que la fin des tests ne serait pas atteinte). Je m'apperçois maintenant que cette assertion était fausse.
Loin d'en maîtriser tous les arcanes, j'ai au moins compris, sur la page de wikipedia, je cite : "On ne connait pas, aujourd'hui, d'algorithme parfait - ils sont tous faillibles dans des conditions données.".
Donc, dans certaines conditions, mon algo, à défaut d'être parfait j'en convient, peut fonctionner sans pour autant faillir.
Il y a certainement d'autres possibilités qui sont hors de ma portée, je m'en rend bien compte. Désolé pour le dérangement, alors, et merci pour l'info (je me coucherai moins bête ce soir).
Bon, la version, je n'ai pas compris, mais ce n'est pas grave, peu importe.
Les modules, ce sont des pilotes de périphériques qui ne sont en théorie chargés que lorsque l'on a besoin d'eux.
Par exemple, ton lecteur n'est pas connecté en permanence à ton PC. Autant ne charger les pilotes que le temps qu'ils sont utiles, et les décharger lorsqu'il n'y en a plus besoin. Ca gagne de la mémoire et du temps cpu (bref, des ressources) qui peuvent être exploitées pour autre chose.
Maintenant, on peut faire ça de deux façons : cherger les modules automatiquement, via des fichiers de configuration, soit le faire à la main, avec les commandes qui vont bien (et comme déjà expliqué). Pour que ça fonctionne, il faut que ce soit l'administrateur du système (root) qui lance ces commandes (modprobe et rmmod). Et évidement, il faut que les modules soient créés par une compilation du noyau, et installés.
Normalement, le noyau est localisé sous /usr/src/linux, et la commande pour compiler les modules est make modules, et pour les installer : make modules_install.
Voilà, en espérant que ça aide.
Je ne comprends pas pourquoi tu aurais du perdre ton calme.
Mon post était là pour aider, pas pour faire la leçon. Si j'avais voulu faire la leçon, je m'y serais pris autrement, je n'aurais pas rédigé mon post de cette façon, voire je n'aurais pas posté du tout.
En ajoutant quelques tests mon algo tiens la route.
Après tout, si on suit l'explication d'Eric (que je comprend tout à fait par ailleurs), on pourrait modifier l'algo de la sorte (j'ai testé le code php ci-dessous, et ça fonctionne....) :
#!/usr/bin/php -q
<?php
if ((!file_exists ("test.lock") && ('$f=fopen ("test.lock", "w")))
{
sleep(10);
fclose ($f);
system ("rm test.lock");
}
else
echo "Echec de vérouillage du fichier";
?>
Pour le tester, je l'ai rendu exécutable (appelons-le f1.php), et ai lancé la commande suivante : $ ./f1.php & ./f1.php
De la sorte, le premier process passe tout de suite en arrière-plan, et rend la main au second.
J'ai bien le résultat attendu : la première instance créé le fichier de lock, tandis que la seconde m'indique l'impossibilité de créer le vérou. Passé 10 secondes, la première instance me rend la main.
Si jamais ce script comporte des erreurs, ne perds pas ton calme, hein. J'espère bien profiter de ce post pour comprendre ce qui ne va pas.
J'avais bien précisé que c'était mon expérience perso (;-)), mais merci pour la précision. Ca me fait d'ailleurs penser que si je me souviens bien, uhci, c'est pour les périph d'interface utilisateur (clavier, souris), et ehci pour les périphériques en usb 2, non ?
Il me semble avoir lu ça quelque part (probablement dans les pages d'aides du noyau, d'ailleurs), mais je n'ai pas de manchot sous la main pour vérifier mes dires....
xfs est le serveur de fontes d'X, et si tu n'as que ce chemin dans xorg, ben il faut que tu aies un serveur xfs-xtt qui tourne.
C'est une solution fort pratique qui permet sur un réseau d'avoir les fontes (en particulier les ttf qui bouffent plein de place, mais pas seulement) installées sur une seule machine. Après, on peut dire aux autres machines de s'adresser au serveur en modifiant la ligne incriminée dans le xorg.conf.
Vérifie quand même que xfs-xtt est lancé, et sinon, ben installe-le !
Si tu ne peux ou ne veux installer xfs-xtt, ajoute tous les chemins de fontes que tu lances à la main avec ta commande xset fp... dans ton xorg.conf, et sacque la ligne concernant ce unix://7100.
En espérant que ça aide...
C'est quel lecteur mp3 (marque, modèle) ?
Il se connecte comment à ton PC (câble série, parallèle (mouarf !), usb ?) ?
Tu utilises quelle version du kernel ?
As-tu vérifié que les modules correspondant sont bien chargés ?
En général (/!\ Expérience perso inside /!\), il faut charger les modules :
usb-ohci, usb-storage, usb-scsi (je ne me souviens plus de l'ordre exact, surtout pour les deux derniers).
Normalement, ces modules se chargent avec la commande modprobe ou insmod.
Après les avoir chargés, tu peux monter ton périphérique. D'ailleurs, ce n'est pas une mauvaise idée que de voir ce qui se passe dans les logs lors du chargement de ces modules. Pour ce faire, deux consoles :
la première fait un $ tail -f /var/log/kern.log, et la seconde fait les modprobes qui vont bien. En passant de l'une à l'autre, on voit ce qui se passe.
Encore mon expérience perso : il n'est pas inutile non plus de faire les opérations dans l'ordre ci-dessous :
1) brancher le périphérique
2) charger les modules
3) monter l'unité
4) faire ce qu'on a à faire avec (transferts de fichiers, etc)
5) démonter l'unité
6) décharger les modules
7) débrancher le périphérique.
Voilà, en espérant que ça aide, comme on dit.
Lorsque ton script veut ouvrir un fichier (appelons-le file.src),
il vérifie d'abord la présence d'un fichier nommé file.src.lock.
Si ce fichier existe, echec.
Sinon, tu créés le fichier de lock,
tu fais ce que tu as à faire sur le fichier file.src.
Quand tu as fini, tu détruis le fichier de lock.
Fin.
En espérant que ça aide.
La commande pour démonter, dans un terminal, c'est umount.
Evidement, si tu es dans le répertoire de montage au moment où tu lances la commande, elle te renvoie bouler :
$ cd /Stockage
/Stockage $ umount /dev/hdb8
Ne fonctionnera pas.
A contrario, ceci :
/Stockage $ cd /
$ umount /dev/hdb8
devrait marcher si aucun fichier présent sur /dev/hdb8 est ouvert.
Pour voir si un fichier est ouvert sur une partition, consulte la page d'aide de la commande lsof, ainsi que les outils comme less et grep. Tu devrais obtenir l'information rien qu'avec ces commandes là.
$lsof | grep hdb8 peut être un bon début. Si tu as beaucoup de fichiers d'ouverts, $ lsof | grep hdb8 | less te fera un affichage page par page.
Maintenant, à l'auteur du message précédent, je n'ai rien compris à ton PS qui me semble complètement à côté de la plaque.....
Ah, ben m* alors !
J'ignorais complètement que Lucky Starr avait été traduit, ainsi que le club des veuf noirs. J'aurais bien aimé les lire, et en agrémenter ma bibliothèque.... Mais comme tu dis, sasfépu, probablement. Je vais mettre à profit le grand ternet et quelques magasins pour voir vraiment ce qu'il en est, et éventuellement me fendre de quelques euros si je trouve !
Excellente nouvelle donc, d'un côté, et cruelle nouvelle d'un autre !
C'est, d'après l'introduction toujours, LA compilation complète des histoires de robots. Elle est classée par types de robots, et se situe avant le cycle des fondations. Bien avant, même. On y parle parfois de l'empire, mais à la louche, je dirais que 99% des histoires se passent avant lui.
J'ai envoyé le lien sur ce livre, mais en fait, j'aurais mieux fait de m'abstenir. Il est constitué de deux volumes, et on retrouve les cavernes d'acier et face aux feux du soleil dans le second.
Tout est dans le titre ou presque.
Si le php fourni avec ta distrib ne convient pas, c'est soit qu'il n'a pas été compilé avec les options qui t'intéressent, soit qu'il te manque un paquet (php-gd.rpm ?).
Quoi qu'il en soit, si tu veux installer à partir des sources, il te faudra probablement les paquages de dev de pas mal de choses. C'est probablement ce qui se passe avec libxml2 qui est installé, mais pas libxml2-dev ou quelque chose d'approchant.
Bref, pour le problème qui te préoccupe, il me semble que php, dans sa version source, débarque avec un gd "forké" de la libgd originelle, et qu'il est conseillé d'utiliser celle-là. Je n'ai pas de manchot sous la main pour vérifier mes dires, mais il me semble qu'un ./configure --enable-gd ou --with-gd est suffisant. A vérifier avec l'aide fournie par le ./configure. D'où le titre :
Munis-toi d'un papier et d'un crayon, ou mieux, d'un second terminal. Dans le premier, tu tapes ./configure --help | less pour voir l'aide, la lire, et récupérer les options qui vont bien, et dans l'autre, tu remplis les options au fil de l'eau, selon ce dont tu as besoin.
Dans une distrib à paquet, ce n'est pas trop conseillé d'installer depuis les sources, car ça casse les dépendances, mais c'est à toi de voir.
Voilà, en espérant que ça aide.
Pour avoir une idée sur la question, et éventuellement pouvoir t'aider, il faudrait peut-être savoir avec quoi tu travailles, non ? C'est du OpenOffice ? Du sgml, du ps, du tex, du bibtex, du LaTeX, etc ?
A te lire, on ne peut faire que des suppositions. Pour ma part, avec mes connaissances, qui sont loin d'être totale dans ce domaine, j'aurais tendance à penser que tu travailles avec tex/LaTeX.
Si j'ai deviné juste, as-tu essayé de compiler plusieurs fois ton document source ?
Je sais que LaTeX est incapable de faire des prédictions à priori sur l'emplacement des objets situés en avant dans le document, et il est parfois nécessaire de faire plusieurs passes. C'est d'ailleurs décrit dans la doc du package pageref, il me semble. Parfois, il faut même jusqu'à trois compilations.
Pour ma part, et pour raconter un peu ma vie, j'utilise exclusivement la commande texi2pdf qui me génère de beaux pdf à partir de mes sources LaTeX, et cette commande invoque à son tour texi2dvi avec l'option -pdf. Elle semble capable de détecter les cas problématiques et anticipe sur le nombre d'appels à la commande de compilation.
En résumé, si j'utilise pageref, elle lance 3 compilations coup sur coup avant de me rendre la main, sinon, elle n'en lance qu'une.
Il est même probable qu'elle se base sur le code de retour de la commande de compilation pour relancer le traitement si nécessaire. Bref, pour le cas qui nous intéresse, on s'en fout.
Essaye donc de compiler une troisième fois, sans supprimer les fichiers temporaires (*.{aux,log,toc}). Si jamais ça ne fonctionnait pas, repart de 0 (en conservant ton source, évidement), car ces fichiers servent plus ou moins de cache....
Je peux me tromper, mais le message derrière le kernel panic n'indique-t-il pas qu'il ne peut charger simultanément le pilote pour piix et ide ?
Apparement, l'appel à spin_lock a déjà été effectué par ce dernier, et piix.C ne peut re-lancer cette fonction.
Pour ce que j'en sais, il semblerait que tu aies compilé ton noyau avec le support générique pour les chipsets PCI et le pilote nécessaire à ta carte (PIIX), ce qui est non seulement redondant, mais inutile.
Je peux me tromper, alors dans ce cas, je fais confiance à la communauté pour rétablir la vérité si toutefois j'ai dit des clowneries.
En espérant que ça aidera à résoudre ton problème.
Je suis bien conscient que le problème est ardu, MAIS, car il y a toujours un MAIS, il y en a bien qui y sont arrivés. Je citerais à cet effet 3com qui a pondu un soft dont j'ai oublié le nom qui permet justement d'obtenir une topologie réseau assez proche de la réalité.
Je soupçonne ce soft (qui est bien propriétaire et bien fermé au passage) d'utiliser SNMP pour arriver à ses fins. Pas seulement SNMP, mais en grande partie.
J'avais commencé à fouiller la MIB provenant des switch de la marque, mais c'est un tel bordel que j'ai abandonné.
Enfin, le but de ce post n'est pas ni d'encenser 3com, ni de le démolir, mais simplement de dire que si ils ont réussi à le faire, c'est que ce doit être possible.
Enfin, un soft qui permettrait d'obtenir un schéma de réseau, graphique, avec les ch'tites icônes qui vont bien, et le plus d'informations possibles sur les éléments du réseau, même incomplet, serait à mon humble avis le bienvenu. C'est quand même plus simple d'ajouter un bridge sur un schéma déjà existant, que de se taper tous les éléments un à un. Surtout quand il y en a beaucoup.
Voilà mon point de vue sur la question.
En effet, Dia est une bonne solution, mais confronté au même problème que l'auteur du journal, j'en profite pour poser une question connexe :
existe-t-il un interface à dia, ou à tout autre programme de dessin de topologie de réseau qui remplirait déjà automatiquement les équipements et leurs connexions ? En utilisant SNMP, ce doit être possible. Tout du moins pour récupérer les adresses IP et MAC des équipements, leut type, et si c'est un switch, de savoir quel équipement est branché sur quelle prise.
Si quelqu'un connait un soft de ce type, qu'il soit sous Linux ou au pire des cas (mais vraiment le pire alors) sous windows, GPL, qu'il le fasse savoir ici même !
Merci par avance !
Quand on peut faire :
TAR=`tar -zcf $PERIF $SRCDIR -X /home/informatique/admin/backup/tar_exclude 2>>$LOGDIR`
Pour avoir une compression au format gzip, ou
TAR=`tar -jcf $PERIF $SRCDIR -X /home/informatique/admin/backup/tar_exclude 2>>$LOGDIR`
pour avoir une compression au format bzip2 (si la commande tar est compilée avec l'option qui va bien) ?
Personnellement, j'utilise la seconde, et ça fonctionne on ne peut mieux.
Je n'ai pas de chiffres sous la main, alors quelqu'un de plus informé que moi pourra {in,con}firmer ce qui suit.
Si tu actives la compression avec ta commande mt, il s'agit de la compression matérielle fournie avec ton lecteur DAT. Il s'agit souvent d'un algo de compression "basique", souvent du zip, d'ailleurs, qui permet de gagner en place, c'est évident. Mais selon le type de données sauvegardées, ce n'est pas forcément l'algo fourni qui est le meilleur. A ta place, je tenterais les 3 (le matériel, le gzip, et le bzip), quitte à en essayer d'autres (compress, etc.) et j'utiliserais celui qui donne le meilleur rapport en fonction des données que je veux sauvegarder.
Enfin, je dis ça, je dis rien, comme on dit.
Ensuite, ce n'est pas le fait d'utiliser l'option de tar qui va bien qui empêche d'extraire un fichier ou un groupe de fichier.
Voilà, en espérant que ça aide....
Es-tu sûr de la version ? D'après http://www.postgresql.org(...) la dernière version en date est la 8.0.3.
Pour faire avancer un peu le schmilblick, j'aimerais bien éclaircir un ou deux points. D'abord, que veux-tu faire ? Parce que ta question n'est pas très bien posée.
Si tu veux installer postgresql 8.0.3, il te faut une version packagée pour ta distribution. C'est à dire que c'est un paquet tout fait avec ce qu'il faut pour que ça s'installe et ça fonctionne comme prévu sur la distribution. Je ne connais pas ubuntu, mais si la version qui t'est proposée à l'installation n'est que la 7.4, c'est
- soit que personne n'a encore conçu de paquet pour ubuntu d'une version plus récente.
- soit que tu utilises le mauvais répertoire/site web/outil d'installation et que les versions qui te sont proposées sont les mauvaises.
Maintenant, si tu veux créer les paquets, prends contact avec ceux qui le font habituellement, ils sauront de donner plus d'indications que je ne pourrais le faire.
Enfin, si tu ne peux vraiment pas installer postgresql v8.0.3 sur ta machine depuis apt-get, tu peux toujours récupérer sur le site officiel les sources et les compiler à la main. Ce n'est pas très compliqué, car bien souvent, ça se résume à exécuter dans un terminal cette suite de commandes :
$ ./configure && make && make install Cependant, saches que cette dernière option n'est vraiment pas conseillée sur une distribution à paquets, car elle casse l'arbre des dépendances, risque de ne pas fonctionner pour cause de manque des paquets de développement, etc. A n'utiliser vraiment qu'en dernier ressort, et je ne saurais être tennu pour responsable des conséquences que ça pourrait avoir sur ton système. Tu es prévenu !
Voilà, j'espère t'avoir au moins un peu éclairci dans ta recherche de la bonne façon d'obtenir ce que tu cherches.
Oui, j'ai le même problème, mais je ne me suis jamais penché sur la question. Je reçois des messages destinés à david.bourgeois, par exemple (c'est celui qui revient le plus souvent), mais aussi adressés à "undisclosed recipients", et plein d'autres.
Probablement un décodage de headers mal fait. Je ne les regarde jamais. Je ne connais pas l'expéditeur, et il m'écrit dans une autre langue que la mienne : poubelle, direct.
Que le filtre du fai soit "éduqué" par les utilisateurs.
Quitte à être validé par le FAI par la suite (cas du Enl@rge y.o.u.r. pen1s, par exemple).
J'espère que c'est plus clair... ;-) !
Ce que tu dis est fort juste.
Je ne voulais pas parler d'un système classant systématiquement TOUS les spams comme tels, mais d'un système qui évite de distribuer ce qui est classifié par tous comme du spam.
Et je me rend bien compte que ce ne serait pas une solution simple, du moins si elle devait être gérée de manière purement automatique.
D'où mon idée. Après tout, les pubs pour le viagr@, cialissofttabs ou autres cochonneries, ça ne trompe personne, ça part directos à la poubelle, non ?
Alors pourquoi se faire ch... à distribuer ces machins.
D'autant plus que ce sont souvent des mails "types" qui sont envoyés à plusieurs millions d'adresses d'un coup. Donc, il y a moyen de filtrer à la source, à mon avis.
Après, pour faire la nique aux listes de diffusions, il me semble que le header d'un spam ou celui d'une liste de diffusion doit différer, non (j'avoue n'avoir jamais regardé les détails.) ?
Le pire, c'est que je n'ai pas souvenir d'avoir fourni mon adresse mail à qui que ce soit (en dehors de mes contacts, évidemment). J'ai une boîte sur caramail pour toutes les inscriptions qui nécessitent une adresse mail, et celle-ci ne reçoit pas un spam (ou si peu...). Par contre, j'ai utilisé mon adresse perso quelques fois pour écrire sur des forums de développeurs, comme php-france chez linusquefr point org, ou la liste des bugs de KDE ou de postgres. Bref, des trucs qui semblent sérieux. (Merci de ne pas mal comprendre ce qui est écrit ci-dessus).
Malheureusement (heureusement, même), ces listes sont parfois archivées avec l'adresse mail des expéditeurs en brut dans les pages d'archives, avec parfois même un lien mailto. Quoi de plus simple pour récupérer une adresse mail à innonder de merdasse ?
Et puis, à partir de là, tu es spammé une fois, c'est foutu. Il se peut qu'il y ait des échanges de listes entre spammeurs. Et puis même, qu'est-ce qui interdit à nos chers FAI de vendre une liste d'adresse.......
Enfin, je ne veux pas être parano non plus, et je n'évoque cette dernière possibilité que pour la réthorique.
Je suis d'accord avec tout ce que tu indiques. Mais bon, il serait bon qu'ils utilisent, à la limite un genre de filtre paramétré par les utilisateurs.
Genre, quand tu reçois un mais pour du Vi@gr4 ou d'un mec qui est le petit cousin du roi de petaouchnock qui veut te fourguer 15 M ¤ ... tout le monde classe comme spam => pas moyen d'avoir un "faux positif". Après, faudrait affiner le système. Genre, en plus de la boîte de réception, avoir un dossier pour les mails étant potentiellement du spam. Et le reste, même pas distribué. Tout le monde y gagnerait. Et eux, et nous.
De cette façon, on aurait dans notre boîte aux lettres que de vrais mails.
Enfin, il me semble. Je suis loin d'être un spécialiste dans le dommaine.
# DTC.
Posté par Gyro Gearllose . En réponse au message bonjour. Évalué à 9.
[^] # Re: Xfs est-il installé et lancé ?
Posté par Gyro Gearllose . En réponse au message polices - fedora3 et openoffice. Évalué à 3.
Bonne continuation.
[^] # Re: Un ch'tit algo...
Posté par Gyro Gearllose . En réponse au message PHP: Lock sur le system de fichier ?. Évalué à 2.
J'ai commis l'erreur de croire que le fait que le test de l'existence du fichier de vérrou et l'ouverture de ce fichier en écriture soient dans le même bloc entraîne de fait la réalisation de ces deux instructions d'une seule traite, sans interruption.
Je comprend maintenant d'où vient le problème, d'autant plus si c'est pour une page web.
[^] # Re: Un ch'tit algo...
Posté par Gyro Gearllose . En réponse au message PHP: Lock sur le system de fichier ?. Évalué à 2.
Merci pour l'info, je comprend pourquoi ça ne peut pas marcher...
Si j'ai bien compris ce que j'ai lu et ce que tu as écrit, ça vient du fait que la première partie du test peut être lancée plusieurs fois en même temps, alors que la seconde n'est pas encore effectuée.
Je pensais, lorsque j'ai écrit ces lignes, que le fait que les tests étaient regroupés dans une seule condition rendait ce test atomique (en tout cas, que la main ne serait pas rendue tant que la fin des tests ne serait pas atteinte). Je m'apperçois maintenant que cette assertion était fausse.
Loin d'en maîtriser tous les arcanes, j'ai au moins compris, sur la page de wikipedia, je cite : "On ne connait pas, aujourd'hui, d'algorithme parfait - ils sont tous faillibles dans des conditions données.".
Donc, dans certaines conditions, mon algo, à défaut d'être parfait j'en convient, peut fonctionner sans pour autant faillir.
Il y a certainement d'autres possibilités qui sont hors de ma portée, je m'en rend bien compte. Désolé pour le dérangement, alors, et merci pour l'info (je me coucherai moins bête ce soir).
[^] # Re: Quelques infos supplémentaires en seraient pas de trop....
Posté par Gyro Gearllose . En réponse au message folder to device block. Évalué à 2.
Les modules, ce sont des pilotes de périphériques qui ne sont en théorie chargés que lorsque l'on a besoin d'eux.
Par exemple, ton lecteur n'est pas connecté en permanence à ton PC. Autant ne charger les pilotes que le temps qu'ils sont utiles, et les décharger lorsqu'il n'y en a plus besoin. Ca gagne de la mémoire et du temps cpu (bref, des ressources) qui peuvent être exploitées pour autre chose.
Maintenant, on peut faire ça de deux façons : cherger les modules automatiquement, via des fichiers de configuration, soit le faire à la main, avec les commandes qui vont bien (et comme déjà expliqué). Pour que ça fonctionne, il faut que ce soit l'administrateur du système (root) qui lance ces commandes (modprobe et rmmod). Et évidement, il faut que les modules soient créés par une compilation du noyau, et installés.
Normalement, le noyau est localisé sous /usr/src/linux, et la commande pour compiler les modules est make modules, et pour les installer : make modules_install.
Voilà, en espérant que ça aide.
[^] # Re: Un ch'tit algo...
Posté par Gyro Gearllose . En réponse au message PHP: Lock sur le system de fichier ?. Évalué à 1.
Mon post était là pour aider, pas pour faire la leçon. Si j'avais voulu faire la leçon, je m'y serais pris autrement, je n'aurais pas rédigé mon post de cette façon, voire je n'aurais pas posté du tout.
En ajoutant quelques tests mon algo tiens la route.
Après tout, si on suit l'explication d'Eric (que je comprend tout à fait par ailleurs), on pourrait modifier l'algo de la sorte (j'ai testé le code php ci-dessous, et ça fonctionne....) :
#!/usr/bin/php -q
<?php
if ((!file_exists ("test.lock") && ('$f=fopen ("test.lock", "w")))
{
sleep(10);
fclose ($f);
system ("rm test.lock");
}
else
echo "Echec de vérouillage du fichier";
?>
Pour le tester, je l'ai rendu exécutable (appelons-le f1.php), et ai lancé la commande suivante : $ ./f1.php & ./f1.php
De la sorte, le premier process passe tout de suite en arrière-plan, et rend la main au second.
J'ai bien le résultat attendu : la première instance créé le fichier de lock, tandis que la seconde m'indique l'impossibilité de créer le vérou. Passé 10 secondes, la première instance me rend la main.
Si jamais ce script comporte des erreurs, ne perds pas ton calme, hein. J'espère bien profiter de ce post pour comprendre ce qui ne va pas.
[^] # Re: Quelques infos supplémentaires en seraient pas de trop....
Posté par Gyro Gearllose . En réponse au message folder to device block. Évalué à 2.
Il me semble avoir lu ça quelque part (probablement dans les pages d'aides du noyau, d'ailleurs), mais je n'ai pas de manchot sous la main pour vérifier mes dires....
# Xfs est-il installé et lancé ?
Posté par Gyro Gearllose . En réponse au message polices - fedora3 et openoffice. Évalué à 3.
C'est une solution fort pratique qui permet sur un réseau d'avoir les fontes (en particulier les ttf qui bouffent plein de place, mais pas seulement) installées sur une seule machine. Après, on peut dire aux autres machines de s'adresser au serveur en modifiant la ligne incriminée dans le xorg.conf.
Vérifie quand même que xfs-xtt est lancé, et sinon, ben installe-le !
Si tu ne peux ou ne veux installer xfs-xtt, ajoute tous les chemins de fontes que tu lances à la main avec ta commande xset fp... dans ton xorg.conf, et sacque la ligne concernant ce unix://7100.
En espérant que ça aide...
# Quelques infos supplémentaires en seraient pas de trop....
Posté par Gyro Gearllose . En réponse au message folder to device block. Évalué à 4.
Il se connecte comment à ton PC (câble série, parallèle (mouarf !), usb ?) ?
Tu utilises quelle version du kernel ?
As-tu vérifié que les modules correspondant sont bien chargés ?
En général (/!\ Expérience perso inside /!\), il faut charger les modules :
usb-ohci, usb-storage, usb-scsi (je ne me souviens plus de l'ordre exact, surtout pour les deux derniers).
Normalement, ces modules se chargent avec la commande modprobe ou insmod.
Après les avoir chargés, tu peux monter ton périphérique. D'ailleurs, ce n'est pas une mauvaise idée que de voir ce qui se passe dans les logs lors du chargement de ces modules. Pour ce faire, deux consoles :
la première fait un $ tail -f /var/log/kern.log, et la seconde fait les modprobes qui vont bien. En passant de l'une à l'autre, on voit ce qui se passe.
Encore mon expérience perso : il n'est pas inutile non plus de faire les opérations dans l'ordre ci-dessous :
1) brancher le périphérique
2) charger les modules
3) monter l'unité
4) faire ce qu'on a à faire avec (transferts de fichiers, etc)
5) démonter l'unité
6) décharger les modules
7) débrancher le périphérique.
Voilà, en espérant que ça aide, comme on dit.
# Un ch'tit algo...
Posté par Gyro Gearllose . En réponse au message PHP: Lock sur le system de fichier ?. Évalué à 2.
il vérifie d'abord la présence d'un fichier nommé file.src.lock.
Si ce fichier existe, echec.
Sinon, tu créés le fichier de lock,
tu fais ce que tu as à faire sur le fichier file.src.
Quand tu as fini, tu détruis le fichier de lock.
Fin.
En espérant que ça aide.
[^] # Re: Propriétaire..
Posté par Gyro Gearllose . En réponse au message Impossible d'écrire dans nouvelle partition. Évalué à 2.
Evidement, si tu es dans le répertoire de montage au moment où tu lances la commande, elle te renvoie bouler :
$ cd /Stockage
/Stockage $ umount /dev/hdb8
Ne fonctionnera pas.
A contrario, ceci :
/Stockage $ cd /
$ umount /dev/hdb8
devrait marcher si aucun fichier présent sur /dev/hdb8 est ouvert.
Pour voir si un fichier est ouvert sur une partition, consulte la page d'aide de la commande lsof, ainsi que les outils comme less et grep. Tu devrais obtenir l'information rien qu'avec ces commandes là.
$lsof | grep hdb8 peut être un bon début. Si tu as beaucoup de fichiers d'ouverts, $ lsof | grep hdb8 | less te fera un affichage page par page.
Maintenant, à l'auteur du message précédent, je n'ai rien compris à ton PS qui me semble complètement à côté de la plaque.....
[^] # Re: Romans policiers et Lucky Starr
Posté par Gyro Gearllose . En réponse au journal De la liberté des érits.. Évalué à 2.
J'ignorais complètement que Lucky Starr avait été traduit, ainsi que le club des veuf noirs. J'aurais bien aimé les lire, et en agrémenter ma bibliothèque.... Mais comme tu dis, sasfépu, probablement. Je vais mettre à profit le grand ternet et quelques magasins pour voir vraiment ce qu'il en est, et éventuellement me fendre de quelques euros si je trouve !
Excellente nouvelle donc, d'un côté, et cruelle nouvelle d'un autre !
[^] # Re: Le grand Livre des Robots...
Posté par Gyro Gearllose . En réponse au journal De la liberté des érits.. Évalué à 1.
J'ai envoyé le lien sur ce livre, mais en fait, j'aurais mieux fait de m'abstenir. Il est constitué de deux volumes, et on retrouve les cavernes d'acier et face aux feux du soleil dans le second.
# Scrute bien l'aide fournie avec configure.
Posté par Gyro Gearllose . En réponse au message pb librairie GD pour php. Évalué à 2.
Si le php fourni avec ta distrib ne convient pas, c'est soit qu'il n'a pas été compilé avec les options qui t'intéressent, soit qu'il te manque un paquet (php-gd.rpm ?).
Quoi qu'il en soit, si tu veux installer à partir des sources, il te faudra probablement les paquages de dev de pas mal de choses. C'est probablement ce qui se passe avec libxml2 qui est installé, mais pas libxml2-dev ou quelque chose d'approchant.
Bref, pour le problème qui te préoccupe, il me semble que php, dans sa version source, débarque avec un gd "forké" de la libgd originelle, et qu'il est conseillé d'utiliser celle-là. Je n'ai pas de manchot sous la main pour vérifier mes dires, mais il me semble qu'un ./configure --enable-gd ou --with-gd est suffisant. A vérifier avec l'aide fournie par le ./configure. D'où le titre :
Munis-toi d'un papier et d'un crayon, ou mieux, d'un second terminal. Dans le premier, tu tapes ./configure --help | less pour voir l'aide, la lire, et récupérer les options qui vont bien, et dans l'autre, tu remplis les options au fil de l'eau, selon ce dont tu as besoin.
Dans une distrib à paquet, ce n'est pas trop conseillé d'installer depuis les sources, car ça casse les dépendances, mais c'est à toi de voir.
Voilà, en espérant que ça aide.
# Hum...
Posté par Gyro Gearllose . En réponse au message problème de mise à jour du numéro de page dans la toc. Évalué à 2.
A te lire, on ne peut faire que des suppositions. Pour ma part, avec mes connaissances, qui sont loin d'être totale dans ce domaine, j'aurais tendance à penser que tu travailles avec tex/LaTeX.
Si j'ai deviné juste, as-tu essayé de compiler plusieurs fois ton document source ?
Je sais que LaTeX est incapable de faire des prédictions à priori sur l'emplacement des objets situés en avant dans le document, et il est parfois nécessaire de faire plusieurs passes. C'est d'ailleurs décrit dans la doc du package pageref, il me semble. Parfois, il faut même jusqu'à trois compilations.
Pour ma part, et pour raconter un peu ma vie, j'utilise exclusivement la commande texi2pdf qui me génère de beaux pdf à partir de mes sources LaTeX, et cette commande invoque à son tour texi2dvi avec l'option -pdf. Elle semble capable de détecter les cas problématiques et anticipe sur le nombre d'appels à la commande de compilation.
En résumé, si j'utilise pageref, elle lance 3 compilations coup sur coup avant de me rendre la main, sinon, elle n'en lance qu'une.
Il est même probable qu'elle se base sur le code de retour de la commande de compilation pour relancer le traitement si nécessaire. Bref, pour le cas qui nous intéresse, on s'en fout.
Essaye donc de compiler une troisième fois, sans supprimer les fichiers temporaires (*.{aux,log,toc}). Si jamais ça ne fonctionnait pas, repart de 0 (en conservant ton source, évidement), car ces fichiers servent plus ou moins de cache....
# Pb de compilation du noyau....
Posté par Gyro Gearllose . En réponse au message [installation] plantage de GRUB. Évalué à 2.
Apparement, l'appel à spin_lock a déjà été effectué par ce dernier, et piix.C ne peut re-lancer cette fonction.
Pour ce que j'en sais, il semblerait que tu aies compilé ton noyau avec le support générique pour les chipsets PCI et le pilote nécessaire à ta carte (PIIX), ce qui est non seulement redondant, mais inutile.
Je peux me tromper, alors dans ce cas, je fais confiance à la communauté pour rétablir la vérité si toutefois j'ai dit des clowneries.
En espérant que ça aidera à résoudre ton problème.
[^] # Re: peut-être une idée
Posté par Gyro Gearllose . En réponse au message Création de schémas de topologie de réseau. Évalué à 2.
Je soupçonne ce soft (qui est bien propriétaire et bien fermé au passage) d'utiliser SNMP pour arriver à ses fins. Pas seulement SNMP, mais en grande partie.
J'avais commencé à fouiller la MIB provenant des switch de la marque, mais c'est un tel bordel que j'ai abandonné.
Enfin, le but de ce post n'est pas ni d'encenser 3com, ni de le démolir, mais simplement de dire que si ils ont réussi à le faire, c'est que ce doit être possible.
Enfin, un soft qui permettrait d'obtenir un schéma de réseau, graphique, avec les ch'tites icônes qui vont bien, et le plus d'informations possibles sur les éléments du réseau, même incomplet, serait à mon humble avis le bienvenu. C'est quand même plus simple d'ajouter un bridge sur un schéma déjà existant, que de se taper tous les éléments un à un. Surtout quand il y en a beaucoup.
Voilà mon point de vue sur la question.
[^] # Re: Il en existe
Posté par Gyro Gearllose . En réponse au message Création de schémas de topologie de réseau. Évalué à 3.
existe-t-il un interface à dia, ou à tout autre programme de dessin de topologie de réseau qui remplirait déjà automatiquement les équipements et leurs connexions ? En utilisant SNMP, ce doit être possible. Tout du moins pour récupérer les adresses IP et MAC des équipements, leut type, et si c'est un switch, de savoir quel équipement est branché sur quelle prise.
Si quelqu'un connait un soft de ce type, qu'il soit sous Linux ou au pire des cas (mais vraiment le pire alors) sous windows, GPL, qu'il le fasse savoir ici même !
Merci par avance !
# Euh...
Posté par Gyro Gearllose . En réponse au journal Sauvegarder sur DAT en activant la compression. Évalué à 4.
A la lecture de ton script, y'a un truc qui me chiffonne....
Pourquoi lancer ces commandes :
mt -f $PERIF compression
TAR=`tar -cf $PERIF $SRCDIR -X /home/informatique/admin/backup/tar_exclude 2>>$LOGDIR`
Quand on peut faire :
TAR=`tar -zcf $PERIF $SRCDIR -X /home/informatique/admin/backup/tar_exclude 2>>$LOGDIR`
Pour avoir une compression au format gzip, ou
TAR=`tar -jcf $PERIF $SRCDIR -X /home/informatique/admin/backup/tar_exclude 2>>$LOGDIR`
pour avoir une compression au format bzip2 (si la commande tar est compilée avec l'option qui va bien) ?
Personnellement, j'utilise la seconde, et ça fonctionne on ne peut mieux.
Je n'ai pas de chiffres sous la main, alors quelqu'un de plus informé que moi pourra {in,con}firmer ce qui suit.
Si tu actives la compression avec ta commande mt, il s'agit de la compression matérielle fournie avec ton lecteur DAT. Il s'agit souvent d'un algo de compression "basique", souvent du zip, d'ailleurs, qui permet de gagner en place, c'est évident. Mais selon le type de données sauvegardées, ce n'est pas forcément l'algo fourni qui est le meilleur. A ta place, je tenterais les 3 (le matériel, le gzip, et le bzip), quitte à en essayer d'autres (compress, etc.) et j'utiliserais celui qui donne le meilleur rapport en fonction des données que je veux sauvegarder.
Enfin, je dis ça, je dis rien, comme on dit.
Ensuite, ce n'est pas le fait d'utiliser l'option de tar qui va bien qui empêche d'extraire un fichier ou un groupe de fichier.
Voilà, en espérant que ça aide....
# PostgreSQL 8.0.4 ?
Posté par Gyro Gearllose . En réponse au message Ubuntu et postgres. Évalué à 2.
Pour faire avancer un peu le schmilblick, j'aimerais bien éclaircir un ou deux points. D'abord, que veux-tu faire ? Parce que ta question n'est pas très bien posée.
Si tu veux installer postgresql 8.0.3, il te faut une version packagée pour ta distribution. C'est à dire que c'est un paquet tout fait avec ce qu'il faut pour que ça s'installe et ça fonctionne comme prévu sur la distribution. Je ne connais pas ubuntu, mais si la version qui t'est proposée à l'installation n'est que la 7.4, c'est
- soit que personne n'a encore conçu de paquet pour ubuntu d'une version plus récente.
- soit que tu utilises le mauvais répertoire/site web/outil d'installation et que les versions qui te sont proposées sont les mauvaises.
Maintenant, si tu veux créer les paquets, prends contact avec ceux qui le font habituellement, ils sauront de donner plus d'indications que je ne pourrais le faire.
Enfin, si tu ne peux vraiment pas installer postgresql v8.0.3 sur ta machine depuis apt-get, tu peux toujours récupérer sur le site officiel les sources et les compiler à la main. Ce n'est pas très compliqué, car bien souvent, ça se résume à exécuter dans un terminal cette suite de commandes :
$ ./configure && make && make install
Cependant, saches que cette dernière option n'est vraiment pas conseillée sur une distribution à paquets, car elle casse l'arbre des dépendances, risque de ne pas fonctionner pour cause de manque des paquets de développement, etc.
A n'utiliser vraiment qu'en dernier ressort, et je ne saurais être tennu pour responsable des conséquences que ça pourrait avoir sur ton système. Tu es prévenu !
Voilà, j'espère t'avoir au moins un peu éclairci dans ta recherche de la bonne façon d'obtenir ce que tu cherches.
[^] # Re: ma vie et le spam....
Posté par Gyro Gearllose . En réponse au journal Idée pour les FAI ?. Évalué à 2.
Probablement un décodage de headers mal fait. Je ne les regarde jamais. Je ne connais pas l'expéditeur, et il m'écrit dans une autre langue que la mienne : poubelle, direct.
[^] # Re: Je suis pas sur que ce soit une bonne idée
Posté par Gyro Gearllose . En réponse au journal Idée pour les FAI ?. Évalué à 3.
Quitte à être validé par le FAI par la suite (cas du Enl@rge y.o.u.r. pen1s, par exemple).
J'espère que c'est plus clair... ;-) !
[^] # Re: Je suis pas sur que ce soit une bonne idée
Posté par Gyro Gearllose . En réponse au journal Idée pour les FAI ?. Évalué à 2.
Je ne voulais pas parler d'un système classant systématiquement TOUS les spams comme tels, mais d'un système qui évite de distribuer ce qui est classifié par tous comme du spam.
Et je me rend bien compte que ce ne serait pas une solution simple, du moins si elle devait être gérée de manière purement automatique.
D'où mon idée. Après tout, les pubs pour le viagr@, cialissofttabs ou autres cochonneries, ça ne trompe personne, ça part directos à la poubelle, non ?
Alors pourquoi se faire ch... à distribuer ces machins.
D'autant plus que ce sont souvent des mails "types" qui sont envoyés à plusieurs millions d'adresses d'un coup. Donc, il y a moyen de filtrer à la source, à mon avis.
Après, pour faire la nique aux listes de diffusions, il me semble que le header d'un spam ou celui d'une liste de diffusion doit différer, non (j'avoue n'avoir jamais regardé les détails.) ?
[^] # Re: Comment faites vous ?
Posté par Gyro Gearllose . En réponse au journal Idée pour les FAI ?. Évalué à 2.
Malheureusement (heureusement, même), ces listes sont parfois archivées avec l'adresse mail des expéditeurs en brut dans les pages d'archives, avec parfois même un lien mailto. Quoi de plus simple pour récupérer une adresse mail à innonder de merdasse ?
Et puis, à partir de là, tu es spammé une fois, c'est foutu. Il se peut qu'il y ait des échanges de listes entre spammeurs. Et puis même, qu'est-ce qui interdit à nos chers FAI de vendre une liste d'adresse.......
Enfin, je ne veux pas être parano non plus, et je n'évoque cette dernière possibilité que pour la réthorique.
[^] # Re: Certains le font...
Posté par Gyro Gearllose . En réponse au journal Idée pour les FAI ?. Évalué à 2.
Genre, quand tu reçois un mais pour du Vi@gr4 ou d'un mec qui est le petit cousin du roi de petaouchnock qui veut te fourguer 15 M ¤ ... tout le monde classe comme spam => pas moyen d'avoir un "faux positif". Après, faudrait affiner le système. Genre, en plus de la boîte de réception, avoir un dossier pour les mails étant potentiellement du spam. Et le reste, même pas distribué. Tout le monde y gagnerait. Et eux, et nous.
De cette façon, on aurait dans notre boîte aux lettres que de vrais mails.
Enfin, il me semble. Je suis loin d'être un spécialiste dans le dommaine.