GNU bug report logs - #45202
pcscd service doesn't respond to SIGTERM

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45202 in the body.
You can then email your comments to 45202 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Raffael Stocker <r.stocker <at> mnet-mail.de>
To: bug-guix <at> gnu.org
Subject: pcscd service (pcsc-lite) doesn't handle run directory properly
Date: Sat, 12 Dec 2020 15:31:22 +0100

Hi,

I use the pcsc-lite package and noticed that the pcscd service is
sometimes not started by shepherd/herd.  If it is started, "herd start
pcscd" gives me the following error message (sorry for the german part):

> herd: Ausnahmefehler während der Ausführung von »start« mit dem Dienst »pcscd«:
> In procedure open-file: No such file or directory: "/var/run/pcscd/pcscd.pid"

The reason seems to be that pcsc-lite creates its pid file in
"/run/pcscd/", but herd expects it in "/var/run/pcscd/".  This leads to
the service not being started when the files in "/run/pcscd/" have not
been cleaned up (or so my interpretation).  In this case, I get the
error message:

> herd: Ausnahmefehler während der Ausführung von »start« mit dem Dienst »pcscd«:
> Throw to key `%exception' with args `("#<&invoke-error program:
> \"/gnu/store/r1yd6czv3r0is0a1gfsrix3gslkba80v-pcsc-lite-1.9.0/sbin/pcscd\"
> arguments: () exit-status: 1 term-signal: #f stop-signal: #f>")'. 

If I delete the "/run/pcscd" directory, the daemon will be started,
although with the first error message from above.

I have been using guix for only a week now and don't know how to edit
service definitions etc., but maybe someone more competent could have a
look at this.

Regards,
Raffael

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Raffael Stocker <r.stocker <at> mnet-mail.de>
Cc: bug-guix <at> gnu.org, 45202-done <at> debbugs.gnu.org
Subject: Re: bug#45202: pcscd service (pcsc-lite) doesn't handle run
 directory properly
Date: Sat, 12 Dec 2020 23:18:32 +0100

[Message part 1 (text/plain, inline)]

Raffael,

Raffael Stocker 写道：
> The reason seems to be that pcsc-lite creates its pid file in
> "/run/pcscd/", but herd expects it in "/var/run/pcscd/".

Thanks for the report!  I'm closing this bug because I believe 
to've fixed it on master.  Pull it and see.

/var/run has no place on modern GNU/Linux.  We should strive to 
migrate all remaining users to /run, but there's no rush.

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Message #16 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Raffael Stocker <r.stocker <at> mnet-mail.de>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: bug-guix <at> gnu.org, 45202-done <at> debbugs.gnu.org
Subject: Re: bug#45202: pcscd service (pcsc-lite) doesn't handle run
 directory properly
Date: Sun, 13 Dec 2020 01:33:34 +0100

Tobias Geerinckx-Rice writes:

> Thanks for the report!  I'm closing this bug because I believe to've fixed it
> on master.  Pull it and see.
>
> /var/run has no place on modern GNU/Linux.  We should strive to migrate all
> remaining users to /run, but there's no rush.

Thanks, that seems to solve this problem.

However, I now noticed a new one: pcscd doesn't seem to be killable
easily (at least not by a TERM signal), so "herd stop pcscd" has
no effect.  Sending a KILL signal and starting with "herd start pcscd"
works without problems, though.

Regards,
Raffael

Message #22 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: Raffael Stocker <r.stocker <at> mnet-mail.de>
Cc: bug-guix <at> gnu.org, 45202 <at> debbugs.gnu.org
Subject: Re: bug#45202: pcscd service (pcsc-lite) doesn't handle run
 directory properly
Date: Sun, 13 Dec 2020 12:49:27 +0100

[Message part 1 (text/plain, inline)]

Raffael,

Raffael Stocker 写道：
> However, I now noticed a new one: pcscd doesn't seem to be 
> killable
> easily (at least not by a TERM signal), so "herd stop pcscd" has
> no effect.  Sending a KILL signal and starting with "herd start 
> pcscd"
> works without problems, though.

I can reproduce this.  Interestingly(?) it only affects the pcscd 
started by Shepherd.

Manual $(guix build pcsc-lite)/sbin/pcscd invocations, both with 
and without --foreground, are eminently killable with TERM alone.

The Shepherd's instance hangs at

 strace: Process 11441 attached
 select(7, [6], NULL, NULL, NULL

with no activity at all when signal 15 is delivered.  I don't know 
any tricks to attach faster to get more leading context.

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Raffael Stocker <r.stocker <at> mnet-mail.de>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: bug-guix <at> gnu.org, 45202 <at> debbugs.gnu.org
Subject: Re: bug#45202: pcscd service (pcsc-lite) doesn't handle run
 directory properly
Date: Mon, 14 Dec 2020 06:54:47 +0100

Tobias Geerinckx-Rice writes:

>> However, I now noticed a new one: pcscd doesn't seem to be killable
>> easily (at least not by a TERM signal), so "herd stop pcscd" has
>> no effect.  Sending a KILL signal and starting with "herd start pcscd"
>> works without problems, though.
>
> I can reproduce this.  Interestingly(?) it only affects the pcscd started by
> Shepherd.
>
> Manual $(guix build pcsc-lite)/sbin/pcscd invocations, both with and without
> --foreground, are eminently killable with TERM alone.

Interesting indeed.  From looking at the source of pcsc-lite (main() in
pcscdaemon.c) it seems it's not modifying its sigmask.  IIRC, child
processes inherit the parent's ignored signals, so if shepherd is
ignoring SIGTERM before a fork() and not resetting to default before an
exec(), pcscd will never receive the SIGTERM.  This might explain the
behaviour.  I have not checked shepherd's source to confirm.

If this is so, it should probably be fixed in shepherd, right?

Regards,
Raffael

Message #40 received at 45202-done <at> debbugs.gnu.org (full text, mbox):

From: Brice Waegeneire <brice <at> waegenei.re>
To: Raffael Stocker <r.stocker <at> mnet-mail.de>
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>, 45202-done <at> debbugs.gnu.org
Subject: Re: bug#45202: pcscd service doesn't respond to SIGTERM
Date: Sat, 03 Jul 2021 20:25:39 +0200

Hello Raffael,

Raffael Stocker <r.stocker <at> mnet-mail.de> writes:

> Interesting indeed.  From looking at the source of pcsc-lite (main() in
> pcscdaemon.c) it seems it's not modifying its sigmask.  IIRC, child
> processes inherit the parent's ignored signals, so if shepherd is
> ignoring SIGTERM before a fork() and not resetting to default before an
> exec(), pcscd will never receive the SIGTERM.  This might explain the
> behaviour.  I have not checked shepherd's source to confirm.
>
> If this is so, it should probably be fixed in shepherd, right?

Thank yu for the analysis of the issue, it helped me a lot to fix it.
The sheperd pcscd serice wasn't using the correct procedure to start the
daemon, it is fixed in e789ce538ed848bacb8f4eb5742f78b965ccf57c.

Cheers,
- Brice

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.