chipcardd4 uses lots of cpu

[Martin Pool]

On my intrepid machine chipcardd4 is using lots of cpu, even though I don't have any chip-card devices. (I have a flash card reader but I'm not using it at present.)

My machine has been up for 15 hours and it's used 3h40m of cpu time.

There are no log messages about it.

An strace of a few seconds is attached. You can see it's pretty busy repeatedly scanning /sys.

[Martin Pool (mbp)]

I think this was automatically installed as a kde dependency. I've removed it for now.

[Alan Lord (theopensourcerer)]

Ahhh; is that where it came from.

I also have it chewing up tons cycles on my laptop but it isn't installed on my desktop (both Intrepid since Alpha5). I do remember installing Kubuntu on a separate partition although I have a shared home partition so perhaps it has come from there?

I will remove it now.

I couldn't work out why I had it/if it was necessary for something. I don't have any smartcards.

Al

[Micha Lenk (micha)]

This is Debian Bug #470629, which has been fixed recently in Debian experimental.

[Aleksandr Panzin (jalexoid)]

Still too much CPU usage for a daemon. chipcardd4 constantly @ about 2-5%. Even though no chipcard reader is installed.(Ubuntu Jaunty)

[Micha Lenk (micha)]

JAlexoid: nobody stated that the bug is fixed for Ubuntu Jaunty. You need at least libchipcard 4.2.2 for a bugfixed version.

Unfortuately Launchpad has no explicit mechanism to track which version is affected and which one is not.

[Philipp Kern (pkern)]

Micha, is there a patch specifically for this problem? Then we could SRU it into Jaunty (as you opened a bug task there).

[Micha Lenk (micha)]

I believe there is no real patch for specifically this problem as trigger based hardware scan should work for a long time now. Simply set hardwareScanInterval=0 in the config file and add a udev trigger script (like the one from Debian) and you're done. The introduction of the udev trigger script in the Debian package was in SVN commit r944: http://svn.debian.org/viewsvn/aqbanking?view=rev&revision=944 (but beware: possibly not complete).

With opening the bug task for Jaunty I tried to get more attention for this bug in the hope to get a fix in the package before the release of Jaunty. However I have to admit that I don't know Ubuntu's release process in detail. So please apologize for any clueless assumptions made before....

[Martin Pool (mbp)]

This still seems to be a problem in Karmic: I booted up this morning and it's used 8m of CPU despite me having no relevant hardware. It seems to still show up in top when my machine's busy deleting lots of files.

[Micha Lenk (micha)]

This bug was fixed in the package libchipcard - 4.2.8-1ubuntu1

---------------
libchipcard (4.2.8-1ubuntu1) karmic; urgency=low

  * Merge from debian unstable, remaining changes:
    - Bump build-depend on debhelper to install udev rules into
      /lib/udev/rules.d, add Breaks on udev to get correct version.
    - On upgrade from old version and with modified rules file rename old
      udev rules file to /etc/udev/rules.d/40_libchipcard-tools.rules
      (instead to /etc/udev/rules.d/z60_libchipcard-tools.rules).
      This is needed due to the patch to Ubuntu's dh_installudev in
      debhelper 7.0.17ubuntu2.

libchipcard (4.2.8-1) unstable; urgency=low

  * New upstream release
    + drop patch 20_gemexpress (included upstream)
    + drop patch 40_scanner_init_improved_error_handling (included upstream)
  * No patches left, so drop dpatch from build-depends and debian/rules.

libchipcard (4.2.7-4) unstable; urgency=low

  * Fix formatting of libchipcard-tools.NEWS file (thanks to lintian).

libchipcard (4.2.7-3) unstable; urgency=low

  * libchipcard-tools: Run init script in boot sequence AFTER hal has been
    started or BEFORE hal has been stopped and fix boot sequence in postinst
    script (untouched configurations only).

libchipcard (4.2.7-2) unstable; urgency=low

  * debian/libchipcard-tools.init: Include file /etc/defaults/libchipcard-tools
    if it exists.
  * Add patch 40_scanner_init_improved_error_handling for propper handling of
    device scanners failing to initialize (closes: #524320).
  * debian/control:
    + minor improvement of the long package description for libchipcard-ctapi0
    + let libchipcard-tools recommend hal (needed by the daemon for automatic
      device detection).

libchipcard (4.2.7-1) unstable; urgency=low

  * New upstream release
    + fixes memory leaks in HAL scanner code (closes: #522885).
    + drops shared library libchipcardd.so.
  * debian/control:
    + drop binary package libchipcardd0
    + split dependencies into multiple lines.
    + add Conflicts/Replaces for removal of now obsolete package libchipcardd0
      on upgrade to current package libchipcard-tools.
  * debian/rules: Drop snippets for package libchipcardd0.
  * drop files debian/libchipcardd0.README.Debian (completely out of date)
    and debian/libchipcardd0.* (now obsolete).
  * now install README.Debian in package libchipcard-tools, the home of the
    daemon binary chipcardd4, the README talks about.

libchipcard (4.2.5-1) unstable; urgency=low

  * New upstream release
    + drop patch 10_halscanner_bugfix (included upstream)
    + modify patch 20_gemexpress to not patch ccid_ifd.xml any more
      (this hunk is included upstream)

libchipcard (4.2.4-3) unstable; urgency=low

  * libchipcard-tools: Suggest installation of packages libtowitoko2 and
    libccid (closes: #520418).
  * Add man pages for chipcard-tool and kvkcard written by Karsten Hilbert
    (closes: #508084). Thanks a lot, Karsten, for your contributions.
  * Add patch 20_gemexpress for improved libccid driver handling
    (closes: #520283). This makes GemPC Express readers work.
 ...

[Roger Bussard (rogerbussard)]

Just a question. I have this same problem, with libchipcard at 4.2.8-1ubuntu1 on an AMD64 machine. Is it because the fix is not there for 64bit?

[Roger Bussard (rogerbussard)]

By the way, this just showed up when I upgraded to karmic from jaunty. Same symptoms as described in comments above.

[Kenyon Ralph (kralph)]

On 2009-11-17T17:25:49-0000, Roger Bussard <email address hidden> wrote:
> Just a question. I have this same problem, with libchipcard at
> 4.2.8-1ubuntu1 on an AMD64 machine. Is it because the fix is not there
> for 64bit?

You have the version of the package that is supposed to fix this:
https://launchpad.net/ubuntu/+source/libchipcard/4.2.8-1ubuntu1/+build/1074110
http://packages.ubuntu.com/source/karmic/libchipcard

You should probably provide more information if this bug appears to
still exist for you.

--
Kenyon Ralph

[Micha Lenk (micha)]

Roger, what is the content of /etc/chipcard/server/chipcardd.conf?
Wild guess: Maybe you have still hardware polling activated due to manual configuration file changes prior to the upgrade...

[Roger Bussard (rogerbussard)]

Probably correct. I deinstalled completely and reinstalled and its no
longer a problem. The complete deinstall removes even custom files, I
believe. Thanks for explaining.

On Tue, 2009-11-17 at 21:26 +0000, Micha Lenk wrote:

> Roger, what is the content of /etc/chipcard/server/chipcardd.conf?
> Wild guess: Maybe you have still hardware polling activated due to manual configuration file changes prior to the upgrade...
>