init script LSB dependencies need upgrading for rsyslog

[Martin-Éric Racine]

insserv: There is a loop between service rsyslog and chipcardd if stopped
insserv: loop involving service chipcardd at depth 3
insserv: loop involving service rsyslog at depth 2
insserv: loop involving service udev at depth 1
insserv: loop involving service sendsigs at depth 4
insserv: loop involving service nullmailer at depth 2
insserv: There is a loop between service rsyslog and chipcardd if stopped
insserv: loop involving service umountnfs at depth 6
insserv: exiting now without changing boot order!

ProblemType: Bug
Architecture: i386
Date: Sat Jan 16 10:35:50 2010
DistroRelease: Ubuntu 10.04
Package: libchipcard-tools 4.2.8-1ubuntu1
ProcEnviron:
 LANGUAGE=fi_FI.UTF-8
 PATH=(custom, user)
 LANG=fi_FI.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.32-10.14-generic
SourcePackage: libchipcard
Tags: lucid
Uname: Linux 2.6.32-10-generic i686

[Micha Lenk (micha)]

Martin-Éric, I don't understand. What exactly is the loop and what do you suggest to do in order to break the loop?

[Martin-Éric Racine (q-funk)]

It's reported by insserv and caused by mismatched boot and shutdown
orders in the LSB headers of the init script shipped with libchipcard;
it causes recursive boot/shutdown conflicts between other packages.
Fixing this requires changing the boot dependency order in
libchipcard's ini script's LSB headers.

On Sun, Jan 17, 2010 at 4:48 PM, Micha Lenk <email address hidden> wrote:
> Martin-Éric, I don't understand. What exactly is the loop and what do
> you suggest to do in order to break the loop?
>
> --
> init script LSB dependencies need upgrading for rsyslog
> https://bugs.launchpad.net/bugs/508305
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “libchipcard” package in Ubuntu: New
>
> Bug description:
> insserv: There is a loop between service rsyslog and chipcardd if stopped
> insserv:  loop involving service chipcardd at depth 3
> insserv:  loop involving service rsyslog at depth 2
> insserv:  loop involving service udev at depth 1
> insserv:  loop involving service sendsigs at depth 4
> insserv:  loop involving service nullmailer at depth 2
> insserv: There is a loop between service rsyslog and chipcardd if stopped
> insserv:  loop involving service umountnfs at depth 6
> insserv: exiting now without changing boot order!
>
> ProblemType: Bug
> Architecture: i386
> Date: Sat Jan 16 10:35:50 2010
> DistroRelease: Ubuntu 10.04
> Package: libchipcard-tools 4.2.8-1ubuntu1
> ProcEnviron:
>  LANGUAGE=fi_FI.UTF-8
>  PATH=(custom, user)
>  LANG=fi_FI.UTF-8
>  SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.32-10.14-generic
> SourcePackage: libchipcard
> Tags: lucid
> Uname: Linux 2.6.32-10-generic i686
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/libchipcard/+bug/508305/+subscribe
>

[Micha Lenk (micha)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Martin-Éric,

Martin-Éric Racine wrote:
> It's reported by insserv and caused by mismatched boot and shutdown
> orders in the LSB headers of the init script shipped with libchipcard;
> it causes recursive boot/shutdown conflicts between other packages.

Yes, but what exactly is the loop in this case? From the initial report
I can see that rsyslog, udev, sendsigs, nullmailer anc chipcardd seem to
be involved, but not how exactly.

Do you have any pointers to documentation/specs explaining the issue in
more detail?

> Fixing this requires changing the boot dependency order in
> libchipcard's ini script's LSB headers.

Yes, I understood this alread. But *how* exactly should I change the
boot dependency?

Regards
  Micha
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktTOUUACgkQWN0/4pnhQbQXQwCfRH92CphtX9LbS2tMoueD6C6m
AEEAniii7v0/x12DLe9vCfN1Yt0Bo5W0
=F0XY
-----END PGP SIGNATURE-----

[Micha Lenk (micha)]

With libchipcard 5.0.0-1 in Ubuntu natty, there is no libchipcard daemon anymore. Hence I mark this bug as "Fix Released".