From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4.2) Gecko/20040308 Description of problem: The hal daemon does not set it pid file. From configure: #### Set up the pid file if ! test -z "$with_pid_file"; then HALD_PID_FILE=$with_pid_file elif test x$operating_system = xredhat ; then HALD_PID_FILE=${LOCALSTATEDIR}/run/haldaemon.pid else HALD_PID_FILE=${LOCALSTATEDIR}/run/hald/pid fi Let's see where its used: grep -rl HALD_PID_FILE * configure configure.in doc/Makefile.in doc/api/Makefile.in doc/spec/Makefile.in examples/Makefile.in examples/volumed/Makefile.in fdi/Makefile.in fdi/10generic/Makefile.in fdi/20freedesktop/Makefile.in hald/Makefile.in hald/haldaemon.in libhal/Makefile.in Makefile.in tools/Makefile.in tools/linux/Makefile.in tools/device-manager/Makefile.in Only the make files and init script uses it. Version-Release number of selected component (if applicable): hal-0.2.97.cvs20040901 How reproducible: Always Steps to Reproduce: 1. service haldaemon stop 2. service haldaemon start Actual Results: [root@buildhost root]# service haldaemon stop Stopping HAL daemon: [FAILED] [root@buildhost root]# service haldaemon start Starting HAL daemon: [ OK ] /etc/init.d/haldaemon: line 31: /var/run/hald/pid: No such file or directory Additional info: looking deeper into this message: /var/run/hald/pid: No such file or directory The /var/run/hald directory doesn't even exist. [root@buildhost root]#ls /var/run console dbus iptraf named saslauthd syslogd.pid utmp crond.pid gpm.pid klogd.pid netreport sshd.pid usb
The initscript is responsible for maintaining the pid file and in the Fedora RPM's the pidfile used is /var/run/haldaemon.pid. If you want to use a different path, then you might need some 'mkdir -p' stuff in e.g. the %pre section of the RPM file. Or something else. If you have a patch for the hal.spec to fix this I'll be happy to apply it.
>The initscript is responsible for maintaining the pid file and in the >Fedora RPM's the pidfile used is /var/run/haldaemon.pid. The initscripts cannot maintain it. How do they know what its pid is after a fork? All software is supposed to write its own pidfile and then the initscripts will use it. Stunnel.c is a good & simple example. Also, the configure should probably be called using: --with-pid-file=redhat >If you have a patch for the hal.spec to fix this I'll be happy >to apply it. I'll send a patch later. Let me get the pid file being created after the fork and then we'll see what other fixing up there is.
OK, I concur, the daemon should be writing the pid file instead. Awaiting your patch. Thanks, David
Created attachment 103767 [details] Patch to create pid The least intrusive way to solve this was to add the HALD_PID_FILE define to config.h and then use it in the hald.c file. I'm testing this patch and it seems to work fine for me. I also found the root of some of my problems. The configure script uses /etc/redhat-release to make some decisions, but that is not a BuildRequires. It really should be for people doing bootstrap builds. It also helps document what contributes to the build process.
Hi, sorry for the lag. I've committed the patch upstream and also modified the hald/haldaemon.in file which is used as a basis for the Red Hat initscript. Will close this bug when I've fixed the spec file and made a new release. Thanks for the patch, David
I've changed the spec file such that --with-pid-file is passed to configure - that way we don't rely on /etc/redhat-release for this package. Available in hal-0.2.98-4.