Hide Forgot
Description of problem: After applying a bunch of recent updates (python-slip, gdm-libs, gdm, chkconfig, openssl, libssh2, libcurl, libtasn1, gnutls, cups-libs, libtasn1, gnutls, openssl, cups, curl, ntsysv, gdm-plugin-fingerprint, gdm-user-switch-applet, python-slip-gtk, python-slip-dbus, libssh2, libcurl, flash-plugin, cups-libs, libmtp-examples), pcscd does not start up properly. In /var/log/messages I find: -------------------------------------------------------------------------------- pcscd: pcscdaemon.c:506:main() pcsc-lite 1.5.2 daemon ready. pcscd: hotplug_libhal.c:490:HPRegisterForHotplugEvents() Could not initialise connection to hald. pcscd: hotplug_libhal.c:491:HPRegisterForHotplugEvents() Normally this means the HAL daemon (hald) is not running or not ready. pcscd: pcscdaemon.c:525:main() SVCServiceRunLoop returned pcscd: pcscdaemon.c:531:at_exit() cleaning /var/run -------------------------------------------------------------------------------- So it seems pcscd cannot communicate with hald and therefore exits immediately. During shutdown, pcscd returns "failed" presumably because it is not running. Version-Release number of selected component (if applicable): pcsc-lite-1.5.2-6.el6.x86_64 hal-0.5.14-11.el6.x86_64 How reproducible: (presumably) always Steps to Reproduce: 1. Apply recent updates 2. Observe messages during startup and shutdown Actual results: pcscd fails to load Expected results: pcscd loads as it did prior to the updates Additional info:
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 ***