Bug 808733
| Summary: | Recent updates prevent communication of pcscd with hald | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | o.h.weiergraeber |
| Component: | pcsc-lite | Assignee: | Bob Relyea <rrelyea> |
| Status: | CLOSED DUPLICATE | QA Contact: | IDM QE LIST <seceng-idm-qe-list> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | ludovic.rousseau |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-05-01 17:41:54 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
o.h.weiergraeber
2012-03-31 11:25:06 UTC
I don't know what the bug is. Maybe hald has been removed/replaced. Since version 1.7.0 (March 2011) pcsc-lite uses libudev instead of (deprecated) libhal. Maybe pcsc-lite 1.7.0 (or more recent) is available for RedHat 6.2. Hmm, is there any additional information I could supply to help resolve this problem? Is the hald process running when you run pcscd? What happens if you start pcscd by hand as described in http://pcsclite.alioth.debian.org/pcsclite.html#support Yes, hald seems to be running: (~): ps -ef | grep hald 68 2217 1 0 17:21 ? 00:00:00 hald root 2218 2217 0 17:21 ? 00:00:00 hald-runner root 2250 2218 0 17:21 ? 00:00:00 /usr/libexec/hald-addon-rfkill-killswitch root 2262 2218 0 17:21 ? 00:00:00 /usr/libexec/hald-addon-leds root 2264 2218 0 17:21 ? 00:00:00 /usr/libexec/hald-addon-generic-backlight root 2266 2218 0 17:21 ? 00:00:00 hald-addon-input: Listening on /dev/input/event7 /dev/input/event0 /dev/input/event1 /dev/input/event6 /dev/input/event2 /dev/input/event4 /dev/input/event10 68 2273 2218 0 17:21 ? 00:00:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket oliver 3433 3340 0 17:49 pts/0 00:00:00 grep hald Starting pcscd by hand as root, followed by CTRL-C, gives me: (#) LIBCCID_ifdLogLevel=0x000F pcscd --foreground --debug --apdu | tee log.txt 00000000 pcscdaemon.c:267:main() pcscd set to foreground with debug send to stderr 00000060 debuglog.c:239:DebugLogSetLevel() debug level=debug 00000019 debuglog.c:268:DebugLogSetCategory() Debug options: APDU 00001385 pcscdaemon.c:506:main() pcsc-lite 1.5.2 daemon ready. 00052926 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x1D6B, PID: 0x0002 00001085 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x1D6B, PID: 0x0001 00001078 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x17EF, PID: 0x1003 00000856 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x1D6B, PID: 0x0001 00001137 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x1D6B, PID: 0x0001 00003248 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x04B3, PID: 0x4485 00000758 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x04B3, PID: 0x310C 00001013 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x04B3, PID: 0x3025 00004255 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x093B, PID: 0x0023 00001650 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x1D6B, PID: 0x0002 00001570 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x1D6B, PID: 0x0001 00001553 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x0483, PID: 0x2016 00001243 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x0A5C, PID: 0x2110 00000940 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x0A5C, PID: 0x2110 00001097 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x0A5C, PID: 0x2110 00000939 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x0A5C, PID: 0x2110 00001316 hotplug_libhal.c:307:get_driver() Looking a driver for VID: 0x1D6B, PID: 0x0001 ^C09294488 pcscdaemon.c:581:signal_trap() Preparing for suicide 01000175 readerfactory.c:1267:RFCleanupReaders() entering cleaning function 00000033 pcscdaemon.c:531:at_exit() cleaning /var/run Hope this helps. It looks like pcscd is started before hald is started or ready. Have a look at how pcscd is started. I do not use RedHat myself so I can't help much more. Indeed, my /etc/rc.d/rc3.d has: ... S25netfs@ S25pcscd@ S26acpid@ S26haldaemon@ S26udev-post@ ... It looks that your suspicion was correct: the system tries to startup pcscd before haldaemon! This is very likely the cause of the problem, and probably easy to fix :-) So I guess at this point the responsible person at RedHat should chime in... This problem has mystified me because I was getting 26pcscd on my RHEL6 system (even though the init.d file for pcsc had chkconfig: 2345 25 80). I presumed it was because of the: Should-Start: udev hal openct line. It turns out that this couldn't have been the case because hal is called haldaemon on RHEL-6 (there's not Provides: hal in the haldaemon script). My pcscd was being moved because I had netfs on. Bug 788474 is the same issue. That person had netfs off. I'm presuming you do was well. If I turn it of: /sbin/chkconfig netfs off Then delete and readd pcscd: /sbin/chkconfig --del pcscd /sbin/chkconfig --add pcscd I now get pcscd at S25pcscd rather than S26pcscd. You can fix this by changing # Should-Start: udev hal openct # Should-Stop: udev hal openct To # Should-Start: udev haldaemon openct # Should-Stop: udev haldaemon openct in /etc/init.d/pcscd then run: /sbin/chkconfig --del pcscd /sbin/chkconfig --add pcscd I'll request pcsc-lite for RHEL 6.4 and get this update in it. bob Thanks a lot for your analysis of the issue. Unfortunately, the fix does not seem to work in my case. First of all, I do have netfs enabled - I never touched its configuration, so it must have been on by default - and have S25pcscd and S26haldaemon nevertheless! And after exactly following your suggestions I am still getting S25pcscd and S26haldaemon in the rc directories. As indicated in my initial post, the problem started immediately after applying a specific set of updates, which included neither pcsc-lite nor haldaemon, but did include chkconfig! Could the culprit be chkconfig itself??? Oliver > First of all, I do have netfs enabled - I never touched its configuration, so > it must have been on by default - and have S25pcscd and S26haldaemon > nevertheless! yes. it's clearly the default (I hadn't touched it myself). I had zeroed in on it because once I determined that the hal name wasn't matching up with the actual hal service, I wanted to see what else could have caused pcscd to move off of 25, so I looked at all the services running at priority 25 and 26 and only netfs seemed to match something in the pcscd file (Required-Start: $local_fs $remote_fs $syslog) I wonder, what priority is netfs running on in your system. > And after exactly following your suggestions I am still getting S25pcscd and > S26haldaemon in the rc directories. Hmm, after changing 'Should-Start:', pcscd should have moved. Here's the version of chkconfig running on my system: [bob@bobslaptop rc.d]$ rpm -q chkconfig chkconfig-1.3.47-1.el6.x86_64 bob Netfs is started as S25netfs (see comment 7). ******************************************************************************* Chkconfig has been updated recently (see my initial post) and with that update the problem started - my machine is running a NEWER version: chkconfig-1.3.49.3-1.el6_2.x86_64 ******************************************************************************* (~): rpm -qi chkconfig Name : chkconfig Relocations: (not relocatable) Version : 1.3.49.3 Vendor: Red Hat, Inc. Release : 1.el6_2 Build Date: Wed 07 Mar 2012 10:25:48 PM CET Install Date: Sat 31 Mar 2012 08:52:37 AM CEST Build Host: x86-004.build.bos.redhat.com Group : System Environment/Base Source RPM: chkconfig-1.3.49.3-1.el6_2.src.rpm Size : 670132 License: GPLv2 Signature : RSA/8, Tue 20 Mar 2012 01:23:05 PM CET, Key ID 199e2f91fd431d51 Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Summary : A system tool for maintaining the /etc/rc*.d hierarchy Description : Chkconfig is a basic system utility. It updates and queries runlevel information for system services. Chkconfig manipulates the numerous symbolic links in /etc/rc.d, to relieve system administrators of some of the drudgery of manually editing the symbolic links. Maybe there is indeed a problem with that version ??? It seems there has been a sudden drop in (visible) activity on this subject... @Bob Relyea Did you try your proposed fix with a fully updated system (i.e. using the current chkconfig package)? Best regards, Oliver *** This bug has been marked as a duplicate of bug 812469 *** |