# [semi-RISOLTO] hal non parte più

## stefanonafets

Ciao a tutti,

oggi ho aggiornato hal, e questo non parte più.

L'errore è il seguente:

```

AppleOne ~ 00.00 # hald --version

HAL package version: 0.5.9

AppleOne ~ 00.00 # hald --daemon=no --verbose=yes

18:24:05.474 [I] hald.c:533: hal 0.5.9

18:24:05.474 [I] hald.c:598: Will not daemonize

18:24:05.475 [I] hald_dbus.c:4807: local server is listening at unix:abstract=/var/run/hald/dbus-tw1ImVYebF,guid=f838fb2e58005f2e49267500467954a5

18:24:05.476 [I] hald_runner.c:299: Runner has pid 1961

18:24:05.476 [W] ci-tracker.c:200: Could not get uid for connection: org.freedesktop.DBus.Error.NameHasNoOwner Could not get UID of name 'org.freedesktop.DBus': no such name

Runner started - allowed paths are '/usr/libexec:/usr/lib/hal/scripts:/usr/bin'

18:24:05.476 [E] hald_dbus.c:4462: Cannot get caller info for org.freedesktop.DBus

18:24:05.477 [I] hald_runner.c:180: runner connection is 0x8093920

18:24:05.477 [I] mmap_cache.c:251: cache mtime is 1182349365

*** [DIE] osspec.c:watch_fdi_files():349 : Unable to initialize inotify: Function not implemented

```

Ovviamente in genere non lo lancio a mano, ma questo è l'unico modo in cui sono riuscito a vedere perchè non partiva (anche se non ci ho capito niente...)

Mi sono riletto il log di emerge (circa l'aggiornamento di hal appunto) e non ci ho trovato niente di anormale.

Ho anche provato a fare un revdep-rebuild, il quale mi dice che non c'è niente da ricompilare.

Scrivendo mi è venuto in mente che forse il problema è il seguente:

```

AppleOne ~ 00.00 # grep INOTIFY /usr/src/linux/.config

# CONFIG_INOTIFY is not set

```

nel senso che effettivamente il messaggio di errore è proprio circa inotify...

Però la configurazione del mio kernel non è cambiata, e fino a prima dell'aggiornamento hal andava tranquillamente...

Boh, mo provo a ricompilare il kernel con inotify attivo e vi fo sapere

[edit]

Dimenticavo,

ovviamente dopo l'aggiornamento di hal ho anche aggiornato i file di configurazione (con etc-update)

[edit 2]

Ho ricompilato il kernel con inotify, adesso hal funziona...

A questo punto le domanda sono:

 - perchè questa versione di hal necessita di inotify e la precedente no?

 - perchè (come molti altri ebuild fanno) l'ebuild di hal non controlla che inotify sia attivo nel kernel?

Tnz

----------

## !equilibrium

 *stefanonafets wrote:*   

>  - perchè questa versione di hal necessita di inotify e la precedente no?

 

http://en.wikipedia.org/wiki/Inotify

riassumendo brevemente:

```
 its functionality permits reindexing of changed files without scanning the filesystem for changes every few minutes, which would entail a lengthy delay and be very CPU intensive.
```

 *stefanonafets wrote:*   

>   - perchè (come molti altri ebuild fanno) l'ebuild di hal non controlla che inotify sia attivo nel kernel?

 

a me l'ha fatto il check, forse in portage c'era una versione dell'ebuild senza quel check.

----------

## Mamon

Anche io ho lo stesso problema, tuttavia inotify Ã¨ giÃ  abilitato nel kernel:

```
grep INOTIFY /usr/src/linux/.config

CONFIG_INOTIFY=y

CONFIG_INOTIFY_USER=y
```

e hal non parte lo stesso.

Qualcuno ha suggerimenti?

----------

## ^Stefano^

Fallo partire a mano come ha fatto stefanonafets e postaci l'errore. A me comunque l'aggiornamento non ha dato alcun problema   :Wink: 

----------

## Mamon

L'errore Ã¨ proprio quello di stefanonafets

----------

## ^Stefano^

prova ad andare a questo link https://bugs.gentoo.org/show_bug.cgi?id=178526

8° e 9° post dicono che il problema è derivato dall'aggiornamento di linux-heders senza la ricompilazione di glibc.

----------

## magowiz

Leggendo lo stesso bug , precisamente commento 18, il problema veniva risolto installando hal-info, infatti avevo lo stesso problema e ho risolto così.

----------

