bug#45202: pcscd service (pcsc-lite) doesn't handle run directory properly

bug#45202: pcscd service (pcsc-lite) doesn't handle run directory properly

[Raffael Stocker]

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

bug#45202: pcscd service (pcsc-lite) doesn't handle run directory properly

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#45202: pcscd service (pcsc-lite) doesn't handle run directory properly

[Raffael Stocker]

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

bug#45202: pcscd service (pcsc-lite) doesn't handle run directory properly

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#45202: pcscd service (pcsc-lite) doesn't handle run directory properly

[Raffael Stocker]

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

bug#45202: pcscd service doesn't respond to SIGTERM

[Brice Waegeneire]

Hello Raffael,

Raffael Stocker <r.stocker@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