C'est très bizarre, mais ça me rappelle un vieux truc que j'ai
eu dans le temps avec, justement, un FreeBSD... Un peu comme si
une table interne du noyau n'était pas au courant de la réalité
du monde extérieur :)
C'est très bizarre, mais ça me rappelle un vieux truc que j'ai
eu dans le temps avec, justement, un FreeBSD... Un peu comme si
une table interne du noyau n'était pas au courant de la réalité
du monde extérieur :)
C'est très bizarre, mais ça me rappelle un vieux truc que j'ai
eu dans le temps avec, justement, un FreeBSD... Un peu comme si
une table interne du noyau n'était pas au courant de la réalité
du monde extérieur :)
PortablePierre-6:~ ple$ ls -l /
../..lrwxr-xr-x@ 1 root admin 11 10 jan 05:27 tmp -> private/tmp
c'est bon.PortablePierre-6:~ ple$ ls -l /tmp/
total 0
-rw------- 1 _www wheel 0 30 jan 01:16 aprUl2oT7
-rw------- 1 _www wheel 0 30 jan 01:16 apryQIFoC
srwxrwxrwx 1 ple wheel 0 30 jan 01:17 com.hp.launchport
drwx------ 3 ple wheel 102 30 jan 01:17 launch-ZTjETV
drwx------ 3 ple wheel 102 30 jan 01:17 launch-vZVjpu
drwx------ 3 ple wheel 102 30 jan 01:17 launch-vlLrhM
drwx------ 3 ple wheel 102 30 jan 01:17 launchd-108.3536To
Là il en manque. En dépit de ce qu'affirme MySQL, netstat et lsof, le
socket n'est pas dans /tmp/Curieux tout ça.
On dirait que mysql se met en route puis s'arrête tout seul, ce qui
fait
qu'au moment où je fais une recherche sur mysql.sock, je ne le trouve
nulle part...
moi j'ai plutôt l'impression que quelque chose supprime le socket. Si un
fichier ouvert par un process, puis supprimé par un autre, il continu
d'exister pour le process qui le lit, mais n'est plus accessible par les
autres process. Ça expliquerait qu'il soit toujours vu comme ouvert,
mais soit inaccessible sur le disque.
Je voudrai que tu essayes l'application fseventer
(<http://www.fernlightning.com>).
Les réglages par défaut devraient contenir.
Donc voilà la manip à faire :
1- tu quittes toutes les appli possibles sauf le terminal
2- tu quittes aussi mysql via la commande :
sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop
3- tu lances fseventer, et tu l'actives (petite flèche verte)
4- tu relances mysql via la commande :
sudo /Library/StartupItems/MySQLCOM/MySQLCOM start
5- tu observes bien ce qu'il se passe dans fseventer, et surtout, tu
traques le socket mysql.sock.
Si il est supprimé à un moment donné, tu devrais voir quel process l'a
fait.
PortablePierre-6:~ ple$ ls -l /
../..
lrwxr-xr-x@ 1 root admin 11 10 jan 05:27 tmp -> private/tmp
c'est bon.
PortablePierre-6:~ ple$ ls -l /tmp/
total 0
-rw------- 1 _www wheel 0 30 jan 01:16 aprUl2oT7
-rw------- 1 _www wheel 0 30 jan 01:16 apryQIFoC
srwxrwxrwx 1 ple wheel 0 30 jan 01:17 com.hp.launchport
drwx------ 3 ple wheel 102 30 jan 01:17 launch-ZTjETV
drwx------ 3 ple wheel 102 30 jan 01:17 launch-vZVjpu
drwx------ 3 ple wheel 102 30 jan 01:17 launch-vlLrhM
drwx------ 3 ple wheel 102 30 jan 01:17 launchd-108.3536To
Là il en manque. En dépit de ce qu'affirme MySQL, netstat et lsof, le
socket n'est pas dans /tmp/
Curieux tout ça.
On dirait que mysql se met en route puis s'arrête tout seul, ce qui
fait
qu'au moment où je fais une recherche sur mysql.sock, je ne le trouve
nulle part...
moi j'ai plutôt l'impression que quelque chose supprime le socket. Si un
fichier ouvert par un process, puis supprimé par un autre, il continu
d'exister pour le process qui le lit, mais n'est plus accessible par les
autres process. Ça expliquerait qu'il soit toujours vu comme ouvert,
mais soit inaccessible sur le disque.
Je voudrai que tu essayes l'application fseventer
(<http://www.fernlightning.com>).
Les réglages par défaut devraient contenir.
Donc voilà la manip à faire :
1- tu quittes toutes les appli possibles sauf le terminal
2- tu quittes aussi mysql via la commande :
sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop
3- tu lances fseventer, et tu l'actives (petite flèche verte)
4- tu relances mysql via la commande :
sudo /Library/StartupItems/MySQLCOM/MySQLCOM start
5- tu observes bien ce qu'il se passe dans fseventer, et surtout, tu
traques le socket mysql.sock.
Si il est supprimé à un moment donné, tu devrais voir quel process l'a
fait.
PortablePierre-6:~ ple$ ls -l /
../..lrwxr-xr-x@ 1 root admin 11 10 jan 05:27 tmp -> private/tmp
c'est bon.PortablePierre-6:~ ple$ ls -l /tmp/
total 0
-rw------- 1 _www wheel 0 30 jan 01:16 aprUl2oT7
-rw------- 1 _www wheel 0 30 jan 01:16 apryQIFoC
srwxrwxrwx 1 ple wheel 0 30 jan 01:17 com.hp.launchport
drwx------ 3 ple wheel 102 30 jan 01:17 launch-ZTjETV
drwx------ 3 ple wheel 102 30 jan 01:17 launch-vZVjpu
drwx------ 3 ple wheel 102 30 jan 01:17 launch-vlLrhM
drwx------ 3 ple wheel 102 30 jan 01:17 launchd-108.3536To
Là il en manque. En dépit de ce qu'affirme MySQL, netstat et lsof, le
socket n'est pas dans /tmp/Curieux tout ça.
On dirait que mysql se met en route puis s'arrête tout seul, ce qui
fait
qu'au moment où je fais une recherche sur mysql.sock, je ne le trouve
nulle part...
moi j'ai plutôt l'impression que quelque chose supprime le socket. Si un
fichier ouvert par un process, puis supprimé par un autre, il continu
d'exister pour le process qui le lit, mais n'est plus accessible par les
autres process. Ça expliquerait qu'il soit toujours vu comme ouvert,
mais soit inaccessible sur le disque.
Je voudrai que tu essayes l'application fseventer
(<http://www.fernlightning.com>).
Les réglages par défaut devraient contenir.
Donc voilà la manip à faire :
1- tu quittes toutes les appli possibles sauf le terminal
2- tu quittes aussi mysql via la commande :
sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop
3- tu lances fseventer, et tu l'actives (petite flèche verte)
4- tu relances mysql via la commande :
sudo /Library/StartupItems/MySQLCOM/MySQLCOM start
5- tu observes bien ce qu'il se passe dans fseventer, et surtout, tu
traques le socket mysql.sock.
Si il est supprimé à un moment donné, tu devrais voir quel process l'a
fait.
mysqld 72 _mysql 12u unix 0x336e000 0t0
/tmp/mysql.sock
mysqld 72 _mysql 12u unix 0x336e000 0t0
/tmp/mysql.sock
mysqld 72 _mysql 12u unix 0x336e000 0t0
/tmp/mysql.sock
En fait, je n¹ai jamais réussi à reproduire ce qu¹on voit sur la
première image :
<http://pierrebrest.free.fr/documents/FichiersInformatique/mySQL/disparition_mysql_sock.png>
--- Dans la fenêtre du terminal ------
PortablePierre-6:~ ple$ sudo launchctl unload -w
/Library/LaunchDaemons/com.mysql.mysqld.plist
launchctl: Error unloading: com.mysql.mysqld
PortablePierre-6:~ ple$ sudo rm
/Library/LaunchDaemons/com.mysql.mysqld.plist
PortablePierre-6:~ ple$
----
A la suite de cela, j¹ai craint le pire, car la commande :
sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop
produisait et produit toujours ceci :
---- Copie Fenêtre du terminal ------
PortablePierre-6:~ ple$ sudo /Library/StartItems/MySQLCOM/MySQLCOM stop
Password:
sudo: /Library/StartItems/MySQLCOM/MySQLCOM: command not found
PortablePierre-6:~ ple$
----
A ce stade, j¹ai remarqué que phpMyAdmin me donnait accès aux bases de
données.
Je n¹ai pas voulu prendre le risque de copier la base de données de spip
dans le dossier data, craignant des problèmes de permissions. Je me suis
donc contenté de réinstaller spip avec la sauvegarde que j¹en avais
faite juste avant la migration par l¹intermédiaire de son interface
d¹administration. Et cela marche parfaitement.
1) Les commandes sudo /Library/StartItems/MySQLCOM/MySQLCOM stop et sudo
/Library/StartItems/MySQLCOM/MySQLCOM start ne fonctionnent plus.
2) J¹ai d¹autres bases de données qui fonctionnaient avec une version de
mysql 5.0.18.
Comment puis-je les envoyer dans mon dossier data sans tout casser ou
sans créer des problèmes de permission ?
3) Pour l¹instant le mot de passe est vide.
Puis-je appliquer sans danger la commande :
mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD('nouveau_mot_de_passe') WHERE
user='root';
En fait, je n¹ai jamais réussi à reproduire ce qu¹on voit sur la
première image :
<http://pierrebrest.free.fr/documents/FichiersInformatique/mySQL/disparition_mysql_sock.png>
--- Dans la fenêtre du terminal ------
PortablePierre-6:~ ple$ sudo launchctl unload -w
/Library/LaunchDaemons/com.mysql.mysqld.plist
launchctl: Error unloading: com.mysql.mysqld
PortablePierre-6:~ ple$ sudo rm
/Library/LaunchDaemons/com.mysql.mysqld.plist
PortablePierre-6:~ ple$
----
A la suite de cela, j¹ai craint le pire, car la commande :
sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop
produisait et produit toujours ceci :
---- Copie Fenêtre du terminal ------
PortablePierre-6:~ ple$ sudo /Library/StartItems/MySQLCOM/MySQLCOM stop
Password:
sudo: /Library/StartItems/MySQLCOM/MySQLCOM: command not found
PortablePierre-6:~ ple$
----
A ce stade, j¹ai remarqué que phpMyAdmin me donnait accès aux bases de
données.
Je n¹ai pas voulu prendre le risque de copier la base de données de spip
dans le dossier data, craignant des problèmes de permissions. Je me suis
donc contenté de réinstaller spip avec la sauvegarde que j¹en avais
faite juste avant la migration par l¹intermédiaire de son interface
d¹administration. Et cela marche parfaitement.
1) Les commandes sudo /Library/StartItems/MySQLCOM/MySQLCOM stop et sudo
/Library/StartItems/MySQLCOM/MySQLCOM start ne fonctionnent plus.
2) J¹ai d¹autres bases de données qui fonctionnaient avec une version de
mysql 5.0.18.
Comment puis-je les envoyer dans mon dossier data sans tout casser ou
sans créer des problèmes de permission ?
3) Pour l¹instant le mot de passe est vide.
Puis-je appliquer sans danger la commande :
mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD('nouveau_mot_de_passe') WHERE
user='root';
En fait, je n¹ai jamais réussi à reproduire ce qu¹on voit sur la
première image :
<http://pierrebrest.free.fr/documents/FichiersInformatique/mySQL/disparition_mysql_sock.png>
--- Dans la fenêtre du terminal ------
PortablePierre-6:~ ple$ sudo launchctl unload -w
/Library/LaunchDaemons/com.mysql.mysqld.plist
launchctl: Error unloading: com.mysql.mysqld
PortablePierre-6:~ ple$ sudo rm
/Library/LaunchDaemons/com.mysql.mysqld.plist
PortablePierre-6:~ ple$
----
A la suite de cela, j¹ai craint le pire, car la commande :
sudo /Library/StartupItems/MySQLCOM/MySQLCOM stop
produisait et produit toujours ceci :
---- Copie Fenêtre du terminal ------
PortablePierre-6:~ ple$ sudo /Library/StartItems/MySQLCOM/MySQLCOM stop
Password:
sudo: /Library/StartItems/MySQLCOM/MySQLCOM: command not found
PortablePierre-6:~ ple$
----
A ce stade, j¹ai remarqué que phpMyAdmin me donnait accès aux bases de
données.
Je n¹ai pas voulu prendre le risque de copier la base de données de spip
dans le dossier data, craignant des problèmes de permissions. Je me suis
donc contenté de réinstaller spip avec la sauvegarde que j¹en avais
faite juste avant la migration par l¹intermédiaire de son interface
d¹administration. Et cela marche parfaitement.
1) Les commandes sudo /Library/StartItems/MySQLCOM/MySQLCOM stop et sudo
/Library/StartItems/MySQLCOM/MySQLCOM start ne fonctionnent plus.
2) J¹ai d¹autres bases de données qui fonctionnaient avec une version de
mysql 5.0.18.
Comment puis-je les envoyer dans mon dossier data sans tout casser ou
sans créer des problèmes de permission ?
3) Pour l¹instant le mot de passe est vide.
Puis-je appliquer sans danger la commande :
mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD('nouveau_mot_de_passe') WHERE
user='root';
1) Les commandes sudo /Library/StartItems/MySQLCOM/MySQLCOM stop et sudo
/Library/StartItems/MySQLCOM/MySQLCOM start ne fonctionnent plus.
StartUpItems
-----^^
Ah flûte, ça m'a échappé. Je commence à manquer de sommeil...
2) J¹ai d¹autres bases de données qui fonctionnaient avec une version de
mysql 5.0.18.
Comment puis-je les envoyer dans mon dossier data sans tout casser ou
sans créer des problèmes de permission ?
j'éviterai de faire ce genre de manip, je préfère injecter un dump.
Néanmoins, si tu veux vraiment le faire (c'est réversible) :
coupe ton serveur mysql :
sudo /Library/StartUpItems/MySQLCOM/MySQLCOM stop
copie tes bases dans le dossier /usr/local/mysql/data/ de préférence
avec un outils graphique, parce que je me sens pas de t'expliquer là
comme ça comment bouger des bases sans risquer la faute de frappe.
Chaque base est un dossier. Chez moi (FreeBSD), les droits sont 700
(drwx------), le user est mysql et le group est mysql.
Tu fais un :
ls -l /usr/local/mysql/data/
pour lire ce qu'il en est vraiment,
et un :
chmod -R 700 /usr/local/mysql/data/*
chmod -R mysql:mysql /usr/local/mysql/data/*
(ATTENTION : change 700 et mysql:mysql en fonction de la réalité du
terrain)
Ensuite tu relances ton serveur, et tu vois si il explose. Si il explose
pas, c'est déjà bien. Si il voit pas les bases alors peut être qu'il
aurait fallu les créer vide, avant de remplacé les vides par tes bases
existantes...
Si il explose, tu vires les fichiers que tu avais ajouté, et tu relances.3) Pour l¹instant le mot de passe est vide.
Puis-je appliquer sans danger la commande :
mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD('nouveau_mot_de_passe') WHERE
user='root';
je préfère :
mysqladmin -u root password "nouveau mot de passe"
Quelle gourde ! Je viens de faire un copier-coller de ce forum vers le
Tu trouveras sans doute intéressant de télécharger les applications
d'administration de MySQL.com :
<http://dev.mysql.com/downloads/gui-tools/5.0.html>
Ils se comportaient parfois étrangement lors de mes derniers tests, mais
ça remonte à loin.
C'est fait.
1) Les commandes sudo /Library/StartItems/MySQLCOM/MySQLCOM stop et sudo
/Library/StartItems/MySQLCOM/MySQLCOM start ne fonctionnent plus.
StartUpItems
-----^^
Ah flûte, ça m'a échappé. Je commence à manquer de sommeil...
2) J¹ai d¹autres bases de données qui fonctionnaient avec une version de
mysql 5.0.18.
Comment puis-je les envoyer dans mon dossier data sans tout casser ou
sans créer des problèmes de permission ?
j'éviterai de faire ce genre de manip, je préfère injecter un dump.
Néanmoins, si tu veux vraiment le faire (c'est réversible) :
coupe ton serveur mysql :
sudo /Library/StartUpItems/MySQLCOM/MySQLCOM stop
copie tes bases dans le dossier /usr/local/mysql/data/ de préférence
avec un outils graphique, parce que je me sens pas de t'expliquer là
comme ça comment bouger des bases sans risquer la faute de frappe.
Chaque base est un dossier. Chez moi (FreeBSD), les droits sont 700
(drwx------), le user est mysql et le group est mysql.
Tu fais un :
ls -l /usr/local/mysql/data/
pour lire ce qu'il en est vraiment,
et un :
chmod -R 700 /usr/local/mysql/data/*
chmod -R mysql:mysql /usr/local/mysql/data/*
(ATTENTION : change 700 et mysql:mysql en fonction de la réalité du
terrain)
Ensuite tu relances ton serveur, et tu vois si il explose. Si il explose
pas, c'est déjà bien. Si il voit pas les bases alors peut être qu'il
aurait fallu les créer vide, avant de remplacé les vides par tes bases
existantes...
Si il explose, tu vires les fichiers que tu avais ajouté, et tu relances.
3) Pour l¹instant le mot de passe est vide.
Puis-je appliquer sans danger la commande :
mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD('nouveau_mot_de_passe') WHERE
user='root';
je préfère :
mysqladmin -u root password "nouveau mot de passe"
Quelle gourde ! Je viens de faire un copier-coller de ce forum vers le
Tu trouveras sans doute intéressant de télécharger les applications
d'administration de MySQL.com :
<http://dev.mysql.com/downloads/gui-tools/5.0.html>
Ils se comportaient parfois étrangement lors de mes derniers tests, mais
ça remonte à loin.
C'est fait.
1) Les commandes sudo /Library/StartItems/MySQLCOM/MySQLCOM stop et sudo
/Library/StartItems/MySQLCOM/MySQLCOM start ne fonctionnent plus.
StartUpItems
-----^^
Ah flûte, ça m'a échappé. Je commence à manquer de sommeil...
2) J¹ai d¹autres bases de données qui fonctionnaient avec une version de
mysql 5.0.18.
Comment puis-je les envoyer dans mon dossier data sans tout casser ou
sans créer des problèmes de permission ?
j'éviterai de faire ce genre de manip, je préfère injecter un dump.
Néanmoins, si tu veux vraiment le faire (c'est réversible) :
coupe ton serveur mysql :
sudo /Library/StartUpItems/MySQLCOM/MySQLCOM stop
copie tes bases dans le dossier /usr/local/mysql/data/ de préférence
avec un outils graphique, parce que je me sens pas de t'expliquer là
comme ça comment bouger des bases sans risquer la faute de frappe.
Chaque base est un dossier. Chez moi (FreeBSD), les droits sont 700
(drwx------), le user est mysql et le group est mysql.
Tu fais un :
ls -l /usr/local/mysql/data/
pour lire ce qu'il en est vraiment,
et un :
chmod -R 700 /usr/local/mysql/data/*
chmod -R mysql:mysql /usr/local/mysql/data/*
(ATTENTION : change 700 et mysql:mysql en fonction de la réalité du
terrain)
Ensuite tu relances ton serveur, et tu vois si il explose. Si il explose
pas, c'est déjà bien. Si il voit pas les bases alors peut être qu'il
aurait fallu les créer vide, avant de remplacé les vides par tes bases
existantes...
Si il explose, tu vires les fichiers que tu avais ajouté, et tu relances.3) Pour l¹instant le mot de passe est vide.
Puis-je appliquer sans danger la commande :
mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD('nouveau_mot_de_passe') WHERE
user='root';
je préfère :
mysqladmin -u root password "nouveau mot de passe"
Quelle gourde ! Je viens de faire un copier-coller de ce forum vers le
Tu trouveras sans doute intéressant de télécharger les applications
d'administration de MySQL.com :
<http://dev.mysql.com/downloads/gui-tools/5.0.html>
Ils se comportaient parfois étrangement lors de mes derniers tests, mais
ça remonte à loin.
C'est fait.
mysqladmin -u root password "nouveau mot de passe"
Quelle gourde ! Je viens de faire un copier-coller de ce forum vers le
terminal et ça a ajouté un saut de ligne de sorte que cela a validé le
mot de passe "nouveau mot de passe".
Seul dernier souci, au bout d'environ 10 mn lorsque le tableau de bord
des préférences MySQL reste affiché à l'écran, j'obtiens le message
désagréable... :
L'application Préférences Système s'est fermée inopinément. Il se peut
que le problème soit provoqué par le module MySQL...
mysqladmin -u root password "nouveau mot de passe"
Quelle gourde ! Je viens de faire un copier-coller de ce forum vers le
terminal et ça a ajouté un saut de ligne de sorte que cela a validé le
mot de passe "nouveau mot de passe".
Seul dernier souci, au bout d'environ 10 mn lorsque le tableau de bord
des préférences MySQL reste affiché à l'écran, j'obtiens le message
désagréable... :
L'application Préférences Système s'est fermée inopinément. Il se peut
que le problème soit provoqué par le module MySQL...
mysqladmin -u root password "nouveau mot de passe"
Quelle gourde ! Je viens de faire un copier-coller de ce forum vers le
terminal et ça a ajouté un saut de ligne de sorte que cela a validé le
mot de passe "nouveau mot de passe".
Seul dernier souci, au bout d'environ 10 mn lorsque le tableau de bord
des préférences MySQL reste affiché à l'écran, j'obtiens le message
désagréable... :
L'application Préférences Système s'est fermée inopinément. Il se peut
que le problème soit provoqué par le module MySQL...
Seul dernier souci, au bout d'environ 10 mn lorsque le tableau de bord
des préférences MySQL reste affiché à l'écran, j'obtiens le message
désagréable... :
L'application Préférences Système s'est fermée inopinément. Il se peut
que le problème soit provoqué par le module MySQL...
pareil. il semble bien buggué.
Faudra attendre la prochaine version (sans doute estampillée 10.5)
Seul dernier souci, au bout d'environ 10 mn lorsque le tableau de bord
des préférences MySQL reste affiché à l'écran, j'obtiens le message
désagréable... :
L'application Préférences Système s'est fermée inopinément. Il se peut
que le problème soit provoqué par le module MySQL...
pareil. il semble bien buggué.
Faudra attendre la prochaine version (sans doute estampillée 10.5)
Seul dernier souci, au bout d'environ 10 mn lorsque le tableau de bord
des préférences MySQL reste affiché à l'écran, j'obtiens le message
désagréable... :
L'application Préférences Système s'est fermée inopinément. Il se peut
que le problème soit provoqué par le module MySQL...
pareil. il semble bien buggué.
Faudra attendre la prochaine version (sans doute estampillée 10.5)
PortablePierre-6:~ ple$ netstat -f unix | grep sql
336e000 stream 0 0 39e8000 0 0 0
/tmp/mysql.sock
Ben il est bien là, pourtant...
Bon, tu n'avais pas joué avec MAMP aussi ?
Fais quand même la seconde commande demandée par PatPro :
ps -auxwww | grep sql
histoire qu'on voit ce qui tourne réellement sur ta pachine.
PortablePierre-6:~ ple$ netstat -f unix | grep sql
336e000 stream 0 0 39e8000 0 0 0
/tmp/mysql.sock
Ben il est bien là, pourtant...
Bon, tu n'avais pas joué avec MAMP aussi ?
Fais quand même la seconde commande demandée par PatPro :
ps -auxwww | grep sql
histoire qu'on voit ce qui tourne réellement sur ta pachine.
PortablePierre-6:~ ple$ netstat -f unix | grep sql
336e000 stream 0 0 39e8000 0 0 0
/tmp/mysql.sock
Ben il est bien là, pourtant...
Bon, tu n'avais pas joué avec MAMP aussi ?
Fais quand même la seconde commande demandée par PatPro :
ps -auxwww | grep sql
histoire qu'on voit ce qui tourne réellement sur ta pachine.
--{ Pierre LASSALLE a plopé ceci: }--PortablePierre-6:mysql ple$ netstat -f unix | grep sql
336e000 stream 0 0 39e8000 0 0 0 /tmp/mysql.sock
^^^^^^^^^^^^^^^PortablePierre-6:mysql ple$ sudo lsof /tmp/mysql.sock
lsof: status error on /private/tmp/mysql.sock: No such file or directory
Et "ls -l /tmp/mysql.sock /private/tmp/mysql.sock" donne quoi ?
PortablePierre-6:~ ple$ ls -l /tmp/mysql.sock /private/tmp/mysql.sock
ls: /private/tmp/mysql.sock: No such file or directory
ls: /tmp/mysql.sock: No such file or directory
Et ça, c'est juste après le netstat du dessus ?C'est ça que je ne comprends pas, c'est qu'il n'y a pas de mysql.sock
C'est très bizarre, mais ça me rappelle un vieux truc que j'ai
eu dans le temps avec, justement, un FreeBSD... Un peu comme si
une table interne du noyau n'était pas au courant de la réalité
du monde extérieur :)
--{ Pierre LASSALLE a plopé ceci: }--
PortablePierre-6:mysql ple$ netstat -f unix | grep sql
336e000 stream 0 0 39e8000 0 0 0 /tmp/mysql.sock
^^^^^^^^^^^^^^^
PortablePierre-6:mysql ple$ sudo lsof /tmp/mysql.sock
lsof: status error on /private/tmp/mysql.sock: No such file or directory
Et "ls -l /tmp/mysql.sock /private/tmp/mysql.sock" donne quoi ?
PortablePierre-6:~ ple$ ls -l /tmp/mysql.sock /private/tmp/mysql.sock
ls: /private/tmp/mysql.sock: No such file or directory
ls: /tmp/mysql.sock: No such file or directory
Et ça, c'est juste après le netstat du dessus ?
C'est ça que je ne comprends pas, c'est qu'il n'y a pas de mysql.sock
C'est très bizarre, mais ça me rappelle un vieux truc que j'ai
eu dans le temps avec, justement, un FreeBSD... Un peu comme si
une table interne du noyau n'était pas au courant de la réalité
du monde extérieur :)
--{ Pierre LASSALLE a plopé ceci: }--PortablePierre-6:mysql ple$ netstat -f unix | grep sql
336e000 stream 0 0 39e8000 0 0 0 /tmp/mysql.sock
^^^^^^^^^^^^^^^PortablePierre-6:mysql ple$ sudo lsof /tmp/mysql.sock
lsof: status error on /private/tmp/mysql.sock: No such file or directory
Et "ls -l /tmp/mysql.sock /private/tmp/mysql.sock" donne quoi ?
PortablePierre-6:~ ple$ ls -l /tmp/mysql.sock /private/tmp/mysql.sock
ls: /private/tmp/mysql.sock: No such file or directory
ls: /tmp/mysql.sock: No such file or directory
Et ça, c'est juste après le netstat du dessus ?C'est ça que je ne comprends pas, c'est qu'il n'y a pas de mysql.sock
C'est très bizarre, mais ça me rappelle un vieux truc que j'ai
eu dans le temps avec, justement, un FreeBSD... Un peu comme si
une table interne du noyau n'était pas au courant de la réalité
du monde extérieur :)