Red Hat Bugzilla – Bug 486427
haldaemon crashes if /dev/ttyS* does not exist
Last modified: 2010-03-30 04:32:48 EDT
Created attachment 332595 [details] extra checks during detection of ttyS-devices Description of problem: The haldaemon crashes if /sys/class/tty/ttyS* exists but /dev/ttyS* has been removed/modified. Version-Release number of selected component (if applicable): hal-0.5.3.8-35.el5 (as released unmodified with CentOS-5.2) How reproducible: 100% Steps to Reproduce: 1. rm -f /dev/ttyS* (or only one of the ttyS-nodes) 2. service haldaemon restart Actual results: Starting HAL daemon: [FAILED] Expected results: Starting HAL daemon: [ OK ] Additional info: Removing/modifying /dev/ttyS* devices is a common advice (i.e. http://lkml.org/lkml/2009/1/29/133) for users with lots of serial-ports. Some PCI-boards with serial-ports provide more than the actual physical ports. A board with support for 4-ports can actually have only 2-ports. If two or more of these PCI-boards are used, the numbering of the ttyS-devices makes no sense for common users. Example: PCI-board #1 provides: ttyS4 - labeled COM5 on the hardware ttyS5 - labeled COM6 on the hardware ttyS6 - not available ttyS7 - not available PCI-board #2 provides: ttyS8 - labeled COM7 on the hardware ttyS9 - labeled COM8 on the hardware ttyS10 - not available ttyS11 - not available With a custom script the serial-ports of these two PCI-boards are removed and created (mknod) again so that the label on the hardware matches the /dev/ttyS* node. /sys/class/tty still contains a complete reference to all the ttyS-devices. hald seems to get confused if devices are listed under /sys/class/tty but are missing under /dev.
Could you please provide a backtrace (with debuginfo for hal) when this happens please.
Created attachment 335496 [details] backtrace with gdb on the crash gdb and haldeamon started with following command: script -f hald-gdb.log -c "gdb --args hald --daemon=no --verbose"
Niels, if I built a test package, would you be able to install it and test a patch? It's a bit tricky to test on my local machine. If it's okay with you, I'll just spin a set of test rpms.
(In reply to comment #3) > Niels, if I built a test package, would you be able to install it and test a > patch? It's a bit tricky to test on my local machine. If it's okay with you, > I'll just spin a set of test rpms. Yes, that's fine. Note that I'm testing on CentOS-5.2, so please no incompatible 5.3 RPMs.
Just a note that the same bug is still there on 5.3 - hal-0.5.8.1-38.el5. Are there any RPMs for testing already? CentOS-5.3 is out, so I'll be able to test any current release. Thanks, Niels
Uhm... the statements above are not really correct any more. As you'll notice my emailaddress changed and now I'm able to run tests on RHEL :)
A tiny check to see if hal_device_property_get_string (d, "linux.device_file") is NULL would fix this. It would be a trivial two line patch.
Built as http://brewweb.devel.redhat.com/brew/taskinfo?taskID=2106624
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0256.html