pcscd service doesn't respond to SIGTERM

  • Done
  • quality assurance status badge
Details
3 participants
  • Brice Waegeneire
  • Tobias Geerinckx-Rice
  • Raffael Stocker
Owner
unassigned
Submitted by
Raffael Stocker
Severity
normal
R
R
Raffael Stocker wrote on 12 Dec 2020 15:31
pcscd service (pcsc-lite) doesn't handle run directory properly
(address . bug-guix@gnu.org)
87o8izhz9h.fsf@mnet-mail.de
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):

Toggle quote (3 lines)
> 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:

Toggle quote (5 lines)
> 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
T
T
Tobias Geerinckx-Rice wrote on 12 Dec 2020 23:18
(name . Raffael Stocker)(address . r.stocker@mnet-mail.de)
87ft4ak6rr.fsf@nckx
Raffael,

Raffael Stocker ???
Toggle quote (3 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCX9VBuA0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15tOMBAIPfrMtqGSHG9aZRTd9dzU4QkMLppa3PgPYSLrk4
PuHDAQCqR/SzDAsUvvureV43khKv2xDiv5Wr1zq3noHBHwC/BA==
=4zvL
-----END PGP SIGNATURE-----

R
R
Raffael Stocker wrote on 13 Dec 2020 01:33
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87im96o881.fsf@mnet-mail.de
Tobias Geerinckx-Rice writes:

Toggle quote (6 lines)
> 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
T
T
Tobias Geerinckx-Rice wrote on 13 Dec 2020 12:49
(name . Raffael Stocker)(address . r.stocker@mnet-mail.de)
87a6uij588.fsf@nckx
Raffael,

Raffael Stocker ???
Toggle quote (7 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCX9X/xw0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15VOkBANbRK0WXxwKz9mBueibIv0wW8cMd4xM1qC6oy1iB
JMLhAQCnfBC22wsL4uhzaGlXTx2tnQ//vasY5usm7QyTntcvAw==
=PKsC
-----END PGP SIGNATURE-----

T
T
Tobias Geerinckx-Rice wrote on 13 Dec 2020 12:49
(no subject)
(address . control@debbugs.gnu.org)
87czzej58a.fsf@nckx
reopen 45202
retitle 45202 pcscd service doesn't respond to SIGTERM
R
R
Raffael Stocker wrote on 14 Dec 2020 06:54
Re: bug#45202: pcscd service (pcsc-lite) doesn't handle run directory properly
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87k0tlvsns.fsf@mnet-mail.de
Tobias Geerinckx-Rice writes:

Toggle quote (11 lines)
>> 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
B
B
Brice Waegeneire wrote on 3 Jul 2021 20:25
Re: bug#45202: pcscd service doesn't respond to SIGTERM
(name . Raffael Stocker)(address . r.stocker@mnet-mail.de)
87v95rcl0c.fsf_-_@waegenei.re
Hello Raffael,

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

Toggle quote (9 lines)
> 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
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 45202@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 45202
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch