# [solved] hald faild to start

## atopo

Starting hald from /etc/init.d/hald fails

When I'm starting it manually I get this:

shuttle atopo # /usr/sbin/hald --daemon=no --verbose=yes

22:15:28.279 [I] hald.c:533: hal 0.5.9

22:15:28.279 [I] hald.c:598: Will not daemonize

22:15:28.280 [I] hald_dbus.c:4807: local server is listening at unix:abstract=/var/run/hald/dbus-ZvDhBDHhRA,guid=d6697763fbdd23f6c6be7d0046a900e0

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

22:15:28.283 [I] hald_runner.c:299: Runner has pid 27667

22:15:28.284 [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

22:15:28.284 [E] hald_dbus.c:4462: Cannot get caller info for org.freedesktop.DBus

22:15:28.284 [I] hald_runner.c:180: runner connection is 0x80937f8

22:15:28.290 [I] mmap_cache.c:251: cache mtime is 1185475966

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

since all this messages tell me nothing I'm asking for your help

thanks

Alexander

----------

## Etal

I think you need to enable Inotify in the kernel:

```
File systems  --->

    [*] Inotify file change notification support
```

and possibly

```

    [*]   Inotify support for userspace
```

Hope this helps!

----------

## shaumux

I think you are not running dbus which is needed by HAL for running.

----------

## atopo

Kernel is built with "Inotify file change notification support" and "Inotify support for userspace", and dbus starts fine.

----------

## shaumux

Do you have correct permissions for starting that.

Try starting it from root account.

----------

## atopo

 *shaumux wrote:*   

> Try starting it from root account.

 

In the starting post is the output when I start it by hand. Output is the same when I start it as root

----------

## Etal

Are your hald and dbus up-to-date?

----------

## atopo

sys-apps/hal-0.5.9-r1

sys-apps/dbus-1.0.2-r2

and I even try to reemerge both of them

didn't help

----------

## cdragan

I had the same problem. Looking at hal source I figured out that the message "Unable to initialize inotify: Function not implemented" comes from an error code from inotify_init(), which in turn is a glibc function. It was implemented and it used to work, so what happened? I recalled that I recently upgraded linux-headers, which is probably the connection between kernel and glibc. So I reemerged glibc and it helped - hal works again.

So the final solution is: reemerge glibc after upgrading linux-headers.

----------

## atopo

 *cdragan wrote:*   

> So the final solution is: reemerge glibc after upgrading linux-headers.

 

After re-emerging glibc and a reboot it looks fine here

thanks

----------

## MickKi

Is a reboot necessary?

I remerged glibc and ran /etc/init.d/hald restart, but it still fails to start.  When I run it by hand this is what I get:

```
# hald --daemon=no --verbose=yes

16:13:17.212 [I] hald.c:533: hal 0.5.9

16:13:17.213 [I] hald.c:598: Will not daemonize

16:13:17.214 [I] hald_dbus.c:4807: local server is listening at unix:abstract=/var/run/hald/dbus-l1iVzXOcIK,guid=361bbed9e87a3611b86e500046b4978d

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

16:13:17.223 [I] hald_runner.c:299: Runner has pid 11502

16:13:17.225 [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

16:13:17.225 [E] hald_dbus.c:4462: Cannot get caller info for org.freedesktop.DBus

16:13:17.225 [I] hald_runner.c:180: runner connection is 0x8096988

16:13:17.228 [I] mmap_cache.c:251: cache mtime is 1184442336

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

Any ideas what's wrong?

EDIT:  I removed /usr/share/hal and tried to remerge it.  It complained that I "MUST" 

compile pciutils without the zlib flag.  Not sure why pciutils has the zlib flag as a default, but if it is causing a problem with hal shouldn't it be removed?

Anyway, after masking zlib for pciutils and remerging both packages it now seems to be working again . . .

----------

