/etc/init.d/opencryptoki stop does not stop pkcsslotd

Here is a debdiff which fixes this: http://launchpadlibrarian.net/19057074/opencryptoki_2.2.6%2Bdfsg-1ubuntu1.debdiff . The debdiff is attached to bug 262708, as it fixes that bug too.

The current init script fails to shut down the pkcsslotd daemon, because start-stop-daemon is passed the --make-pid and --pidfile options, and pkcsslotd fork()'s very early on meaning that the PID of the new process is different to the PID stored in the PID file. Although this doesn't have an immediate impact on users (other than being unable to shut down pkcsslotd), it causes the packages prerm script to fail when removing or upgrading the package. This may cause future Intrepid to Jaunty upgrades to fail.

This has been fixed in Debian, and so I have backported the patch for Ubuntu. The patch makes use of the fact that pkcsslotd creates it's own PID file in /var/lib/opencryptoki/.slotpid. To make this work, I specify this location as the PID file and remove the --make-pid option from start-stop-daemon. As the PID file created by pkcsslotd contains the correct PID, the init script now successfully shuts down pkcsslotd.

***TEST CASE***
Testing the old implementation is difficult, as the 2.2.6+dfsg-1 version of opencryptoki is uninstallable (bug 262708). However, to test version 2.2.6+dfsg-1ubuntu1:
1) Run "sudo /etc/init.d/opencryptoki start" and verify pkcsslotd process exists.
2) Run "sudo /etc/init.d/opencryptoki status" and make sure that it indicates the correct status (running).
3) Run "sudo /etc/init.d/opencryptoki stop" and verify that the pkcsslotd process has gone.
4) Run "sudo /etc/init.d/opencryptoki status" and make sure that it indicates the correct status (not running).

Fixed in Jaunty:

 opencryptoki (2.2.6+dfsg-2) unstable; urgency=medium
 .
   * Applying patch from Philipp Matthias Hahn <email address hidden> to
     correct init script and stop pkcsslotd (Closes: #463763).
   * Adding conflicts/replaces against previous version in order to allow
     upgrades from pre-frozen lenny to frozen/final lenny (Closes: #492156).

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I've done the comulative updates (7 days from now) and still with the problem, even with the -proposed enabled. I can confirm that the workaround https://bugs.launchpad.net/bugs/290874 works to ensure a proper upgrade.

I'm not sure which workaround you refer to, as you linked to this bug report. Can you describe the problem that you are still experiencing and describe the steps to recreate it (ie, does it happen during package install, or an upgrade? If it was an upgrade, was it just a normal update or were you upgrading from an earlier Ubuntu release?)

Dear Chris Coulson,

On Nov 29, Chris Coulson wrote:
> I'm not sure which workaround you refer to, as you linked to this bug
> report. Can you describe the problem that you are still experiencing and
> describe the steps to recreate it (ie, does it happen during package
> install, or an upgrade? If it was an upgrade, was it just a normal
> update or were you upgrading from an earlier Ubuntu release?)

the notebook in question has been upgraded from 8.04 to 8.10, but at an
earlier stage, without a problem with respect to 'opencryptoki'.
This error occured from a '-proposed' upgrade with 8.10 (intrepid) itself.

I did find a solution for me, but it won't work for everyone, I assume,
as it required manual intervention.

The problem arose from the (old) init-script '/etc/init.d/opencryptoki'
giving a non-zero return value on 'stop' due to the fact that the 'start'
didn't successfully start the 'pkcsslotd'. Thus dpkg received an error
(from the 'stop') when trying to remove/upgrade the package, which went
up to the upgrade-manager.

My 'solution' was to put an 'exit 0' in the 'stop' branch before the
call to stop the daemon. This way the upgrade was done and I was only
asked if I wanted to actually replace /etc/init.d/opencryptoki (or
keep the old version), where I answered to install the new init-script
to. From then on, I had no problems any longer.

I think I do see the '--oknodo'-option in the 'stop'-case not present in
the older script. The problem is, that the old script won't be successfully
executed as long as it isn't swapped for the new one, thus aborting the
upgrade(s). When you've got more than one (error-)message for that problem
from me, it's from my trials do make the upgrade succeed; but it's actually
a 'one-time' event.

I'm fine the way it is, now. But I do think you might have to help other
people with the same problem.

Thanks for caring and for the fine software,
 Ruediger Oberhage
--
Dr. H.-R. Oberhage
Mail: Univ. Duisburg-Essen E-Mail: <email address hidden>
      Fachbereich Physik <email address hidden>
      Campus Duisburg, MG 464
      Lotharstrasse 1 Phone: {+49|0} 203 / 379-4736
      47057 Duisburg, Germany FAX: {+49|0} 203 / 379-4732

I see the problem. When I did the patch for Intrepid I didn't think I had to handle upgrades from older broken versions, as the previous Intrepid version of opencryptoki wasn't even installable. What I didn't realise is that the Hardy version suffers the same bug, and people are actually running this version and may upgrade from Hardy with it. So, Hardy needs a similar patch to handle the upgrade from Hardy -> Intrepid.

Currently, then old prerm script will always fail on Hardy -> Intrepid upgrade. What I propose then is implementing the same patch for Hardy SRU, but also adding a "failed-upgrade" action in the new prerm script, which will terminate the pkcsslotd daemon independently of the init script when upgrading from the older version. This should then allow a successful Hardy -> Intrepid upgrade.

I don't mind working on that as long as nobody objects.

Hang on, I'm wrong! I shouldn't have just skimmed through your post before replying ;)

Ok, so what you're saying is that the stop action failed during the upgrade because the daemon had failed to start earlier for some other reason. Missing the "--oknodo" option from start-stop-daemon would cause this, and you should probably open another bug report for that as the stop action should always exit gracefully if the daemon is not running (that issue is separate from this bug).

Thanks for spotting that.

Other than that, can you verify that the Intrepid fix for this original bug works, by running the test case above?

Hi Chris,

Chris Coulson [2008-12-01 20:35 -0000]:
> Currently, then old prerm script will always fail on Hardy -> Intrepid
> upgrade. What I propose then is implementing the same patch for Hardy
> SRU, but also adding a "failed-upgrade" action in the new prerm script,

Maybe you meant that, but it's ambiguous here: bugs in hardy's prerm
scripts shouldn't be fixed in hardy SRUs, but in intrepid SRUs by
implementing a failed-upgrade in the intrepid prerm script (which can
clean up after hardy). Reason is that probably few people will do a
hardy-updates upgrade before doing an upgrade to intrepid.

See http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

Martin,

Thanks for pointing that out. In this case though, I don't think there is any other change necessary as H.-R. Oberhage seems to be experiencing a different bug, which is unrelated to this one (I misread his comment the first time before replying).

On Dec 01, Chris Coulson wrote:
> Hang on, I'm wrong! I shouldn't have just skimmed through your post
> before replying ;)

I did hang on :-).

> Ok, so what you're saying is that the stop action failed during the
> upgrade because the daemon had failed to start earlier for some other
> reason. Missing the "--oknodo" option from start-stop-daemon would cause
> this, and you should probably open another bug report for that as the
> stop action should always exit gracefully if the daemon is not running
> (that issue is separate from this bug).

Quite right. The remark "/etc/init.d/opencryptoki stop does not stop
 pkcsslotd" is correct, but only since pkcsslotd didn't run in the first
place, somehow dying after the '/etc/init.d/opencryptoki start' at startup.
And (only) because of the missing "--oknodo" in the 'previous(!)'
/etc/init.d/opencryptoki this lets the upgrade go wrong!

> Thanks for spotting that.

You're welcome.
But: should I really open a separate bug report because of the then(!)
missing "--oknodo"? It is included in the actual version of the startup-
script, so it has already been spottet and fixed by someone, probably even
you. It used to be wrong, but isn't any longer. The problem 'just' is, how
to get rid of that bad version for people, like me, with that script
   a n d where the daemon didn't stay around, as the error then prevents
the upgrade. Otherwise, i.e. with a working daemon, the upgrade most likely
succeeds.

> Other than that, can you verify that the Intrepid fix for this original
> bug works, by running the test case above?

Which test case do you mean, exactly?
I can tell that with the new /etc/init.d/opencryptoki, a stop doesn't lead
to an error, even when the pkcsslotd doesn't run, but prints
"Stopping PKCS#11 slot daemon: pkcsslotd." as it would, when actually
terminating the pkcsslotd. Better yet, starting the machine or giving a
"/etc/init.d/opencryptoki start" actually makes and keeps pkcsslotd running
after the upgrade now - at least for me.

Is that, what you wanted to know?

For me to test if an upgrade would succeed from the 'bad' version, I would
have to re-install that. But I doubt that anything would change, it would
still go wrong, as the "stop" would produce the error in the startup-script
again.
But when you tell me, I'll try to restore that/an old version and see if
the upgrade works.

Best regards,
 Ruediger

Thanks. The test-case for this SRU is detailed in https://bugs.edge.launchpad.net/ubuntu/+source/opencryptoki/+bug/290874/comments/1. Basically, I just need you to verify that running "sudo /etc/init.d/opencryptoki stop" actually stops the daemon with no error, as the original bug caused the init script to exit with an error (without actually stopping the daemon). The test case needs to be executed after upgrading to the latest Intrepid version of opencryptoki (2.2.6+dfsg-1ubuntu1 from intrepid-proposed).

This bug was fixed in the package opencryptoki - 2.2.6+dfsg-1ubuntu1

---------------
opencryptoki (2.2.6+dfsg-1ubuntu1) intrepid-proposed; urgency=low

  * debian/libopencryptoki0.install:
    - Remove conflicting files from libopencryptoki0
      (LP: #262708 and Debian: #492156).
  * debian/opencryptoki.init:
    - Remove use of --make-pid option from start-stop-daemon and specify
      PIDFILE location of /var/lib/opencryptoki/.slotpid, as pkcsslotd
      creates its own PID file. The problem with the --make-pid option
      is that pkcsslotd fork()'s very early on, so that the
      PID of the child process is not the same as the one recorded in the
      PID file. This causes the init script to fail to shut down pkcsslotd
      when asked too. (LP: #290874 and Debian: #463763)

 -- Chris Coulson <email address hidden> Wed, 29 Oct 2008 22:50:28 +0000