Bug 244958 - sysutils/hal: hald crashes upon startup
Summary: sysutils/hal: hald crashes upon startup
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-gnome (Nobody)
Keywords: crash, needs-qa
Depends on:
Blocks: 244880
  Show dependency treegraph
Reported: 2020-03-21 17:27 UTC by Patrick McMunn
Modified: 2020-10-21 02:27 UTC (History)
2 users (show)

See Also:
koobs: maintainer-feedback? (gnome)


Note You need to log in before you can comment on or make changes to this bug.
Description Patrick McMunn 2020-03-21 17:27:47 UTC
I noticed that when starting the hald service, it would create /var/run/hald/dbus-xxxxxxxxxx files, but there was no indication in top or KDE's system monitor that it was remaining resident, so I tried running the suggested commands in the hald man page for debugging. Hal is indeed crashing upon startup, but it apparently isn't built with the necessary flags for a backtrace. Here's the output I got:

root@l875d-s7210:/home/patrick # gdb /usr/local/sbin/hald
GNU gdb (GDB) 9.1 [GDB v9.1 for FreeBSD]
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.1".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/sbin/hald...
(No debugging symbols found in /usr/local/sbin/hald)
(gdb) run --daemon=no --verbose=yes
Starting program: /usr/local/sbin/hald --daemon=no --verbose=yes
12:15:08.070 [I] hald.c:673: hal 0.5.14
12:15:08.071 [I] hald.c:674: using child timeout 250s
12:15:08.071 [I] hald.c:739: Will not daemonize
12:15:08.072 [I] hald_dbus.c:5444: local server is listening at unix:path=/var/run/hald/dbus-VeEzQY3Rz6,guid=d5b94d38752c3dabd44984165e764b9c
12:15:08.078 [I] ck-tracker.c:396: got seat '/org/freedesktop/ConsoleKit/Seat1'
12:15:08.079 [I] ck-tracker.c:323: got session '/org/freedesktop/ConsoleKit/Session2' for seat '/org/freedesktop/ConsoleKit/Seat1'
12:15:08.084 [I] ck-tracker.c:274: Got active state (ACTIVE) and uid 1001 on session '/org/freedesktop/ConsoleKit/Session2'
12:15:08.084 [I] ck-tracker.c:344: Got all sessions on seat '/org/freedesktop/ConsoleKit/Seat1'
12:15:08.084 [I] ck-tracker.c:423: Got seats
12:15:08.084 [I] ck-tracker.c:824: Got seats and sessions
[Detaching after fork from child process 1743]
12:15:08.295 [I] hald_runner.c:304: Runner has pid 1743
[New LWP 101545 of process 1741]
Runner started - allowed paths are '/usr/local/libexec:/usr/local/libexec/hal/scripts:/usr/local/bin'
12:15:08.304 [I] hald_runner.c:184: runner connection is 0x800de2140
12:15:08.306 [I] hf-ata.c:258: unable to open /dev/ata: No such file or directory
[WARN  1741] polkit-error.c:143:const char *polkit_error_get_error_message(PolKitError *)(): error != NULL
 Not built with -rdynamic so unable to print a backtrace
*** [DIE] hald.c:main():790 : Could not init PolicyKit context: (null)
[LWP 101545 of process 1741 exited]
[Inferior 1 (process 1741) exited with code 01]
(gdb) bt
No stack.
Comment 1 Hans Petter Selasky freebsd_committer 2020-10-18 09:04:21 UTC
Maybe you can "ktrace -d" hald during startup. Then run kdump to get the system call list.

Comment 2 Patrick McMunn 2020-10-21 02:27:44 UTC
Well, I went to run ktrace on hald, but I discovered that hal was working fine. I tested on my server running 13-current, a testing laptop with 12-rc2, and I even pulled an old desktop out of storage that had 12-stable on it which probably hadn't been used in well over a year, and all three machines had hald working. When I experienced this crash, it was on a laptop which no longer has FreeBSD on it. Whatever the nature of the crash was, it may have been an issue particular to that laptop or something about its setup that I have not reproduced elsewhere. I'm guessing this should be closed as "overcome by events".