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
?