Ubuntu
opencryptoki package

opencryptoki postinst fails when pkcsslotd is already running

Bug #963565 reported by Thomas Bushnell, BSG
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
opencryptoki (Ubuntu)
New
Undecided
Unassigned

Bug Description

Version 2.3.1+dfsg-3ubuntu4.

opencryptoki postinst does
  invoke-rc.d opencryptoki start || exit $?

In turn, /etc/init.d/opencryptoki [start] does
  start-stop-daemon --start --quiet --pidfile "/var/lib/opencryptoki/.slotid --exec /usr/sbin/pkcsslotd --

But if pkcsslotd is already running, this fails.

# /etc/init.d/opencryptoki stop
Stopping PKCS#11 slot daemon: pkcsslotd.
# echo $?
0
# /etc/init.d/opencryptoki start
Starting PKCS#11 slot daemon: # echo $?
1

Note as well that when it fails, it fails badly (no newline or error message).

Here is the error from pkcsslotd:

# ps augxw | grep pkcsslotd
root 6351 0.0 0.0 20164 896 pts/0 S+ 16:35 0:00 grep --color=auto pkcsslotd
# /usr/sbin/pkcsslotd
# echo $?
0
# /usr/sbin/pkcsslotd
  ERROR pkcsslotd[6395.755480320]: Shared memory creation failed (0x11)
  ERROR pkcsslotd[6395.755480320]: perform ipcrm -M 0x62000E67
# echo $?
1

Revision history for this message
Thomas Bushnell, BSG (tbushnell) wrote :

It is possible that this is the root cause underlying https://bugs.launchpad.net/ubuntu/+source/opencryptoki/+bug/963533.

Revision history for this message
Thomas Bushnell, BSG (tbushnell) wrote :

Whoops, error in editing. the transcript of the failing init.d script should look like this:

# /etc/init.d/opencryptoki stop
Stopping PKCS#11 slot daemon: pkcsslotd.
# echo $?
0
# /etc/init.d/opencryptoki start
Starting PKCS#11 slot daemon: pkcsslotd.
# echo $?
0
# /etc/init.d/opencryptoki start
Starting PKCS#11 slot daemon: # echo $?
1

Revision history for this message
Stéphane Graber (stgraber) wrote :

The question is why was pkcsslotd still running... I'd expect the prerm to stop it and postinst to start it, making the only failing case happen if someone manually starts it at the middle of the upgrade.

Is that a case where "stop" doesn't actually stop pkcsslotd?
I did a few tests here and it seems to always stop/start reliably and return 0 as expected (unless you start it twice).

An easy workaround is to make the init script return 0 if the daemon is already running but I'm not sure returning 1 in that case is really wrong.

Revision history for this message
Thomas Bushnell BSG (tb-becket) wrote :

Are you sure that every old version of the package correctly stopped the daemon in the prerm?

(Hey, that might explain why the other bug I noted was happening.)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.