sudo /usr/sbin/hald --daemon=no --verbose=yes
00:37:24.853 [I] hald.c:673: hal 0.5.14
00:37:24.853 [I] hald.c:674: using child timeout 250s
00:37:24.853 [I] hald.c:739: Will not daemonize
00:37:24.853 [I] hald_dbus.c:5444: local server is listening at unix:abstract=/var/run/hald/dbus-pKta4h62HT,guid=f6c2f0b867bc76bfcc32d17e4b58e534
00:37:24.855 [I] hald_runner.c:304: Runner has pid 21429
Runner started - allowed paths are '/usr/lib/hal:/usr/lib/hal/scripts:/usr/bin'
00:37:24.856 [I] hald_runner.c:184: runner connection is 0x980cae0
00:37:24.860 [W] osspec.c:388: Unable to open /proc/mdstat: No such file or directory
00:37:24.862 [I] mmap_cache.c:278: cache mtime is 1261563752
Error binding udev_event socket: Address already in use
~/ zgrep -i inotify /proc/config.gz
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
Une idée de l'origine du problème ?
Dernière modification par Hiéroglyphe le ven. 22 janv. 2010, 15:17, modifié 1 fois.
j'obtiens le même phénomène que toi (en lançant la même commande que toi), mais parce que j'ai déjà hal qui tourne.
Tu es sur que hal ne tourne pas ? Un petit :
Si tu regardes /etc/rc.d/hal, tu verras que pour arrêter le démon, le script se base sur le contenu du fichier /var/run/hald.pid, qui doit contenir le pid du démon hal.
- Est-ce que ce fichier existe ?
- S'il existe, quel est son contenu ? Cela devrait être 1768, mais j'en doute dans ton cas.
Si le fichier n'existe pas ou ne contient pas 1768, c'est que le démon a été lancé manuellement, et pas via le /etc/rc.d/hal.
La majorité des bugs se situe entre la chaise et le clavier...
Arrêtez de vous prendre la tête avec les partitions... passez au LVM
/var/run/hald.pid n'était effectivement pas le même... alors histoire de revérifier, j'ai effacé le fichier (inutile?), j'ai rebooté et err... je ne sais pas trop ce qui sait passé, mais hal remarche maintenant
Curieux...