guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#32358] Add pcscd service


From: Chris Marusich
Subject: [bug#32358] Add pcscd service
Date: Mon, 13 Aug 2018 00:18:41 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hi Clément!

Clément Lassieur <address@hidden> writes:

> Hi all!
>
> Chris Marusich <address@hidden> writes:
>
>> Hi Arun,
>>
>> It turns out that when we run pcscd in the foreground with the -f
>> option, it won't emit messages to syslog.  Instead, it emits messages to
>> stderr, and those messages will not be stored in logs, as explained in
>> the following bug report:
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30939
>>
>> To ensure users can easily find the messages, I think we should avoid
>> using the "-f" option.
>>
>> In addition, pcscd logs its PID to /var/run/pcscd/pcscd.pid.  To ensure
>> that Shepherd can still tell if the service is alive even when we do not
>> run it in the foreground, we should invoke make-forkexec-constructor
>> with the #:pid-file keyword argument.
>
> Without the '-f' option, pcscd would return immediately, and thus
> calling MAKE-FORKEXEC-CONSTRUCTOR wouldn't make sense.  Instead, you
> could just INVOKE it.  See the 'prosody', 'postgres' and 'nginx'
> services for examples.  And you could stop it by sending SIGTERM to the
> PID in /var/run/pcscd/pcscd.pid I guess.

Thank you for mentioning this.  You make a good point.  I'm not yet
familiar with all the different ways Shepherd manages its herd of
processes.  For example, I know Shepherd looks for the #:pid-file when
first starting the process to determine whether it started up
successfully.  However, I don't know if Shepherd uses that PID file for
anything else while managing the process later on.

In any case, the procedure make-forkexec-constructor seems to hide a lot
of the nitty gritty details (e.g., closing file descriptors), so I think
it would be better to use it instead of invoking pcscd on our own if we
don't have to.

Perhaps we can do the following:

* Run pcscd in the foreground (with -f).
* Use make-forkexec-constructor.
* Tell Shepherd about the PID file via the #:pid-file option to
  make-forkexec-constructor.
* Redirect pcscd's stdout/stderr to /var/log/pcscd via the #:log-file
  option to make-forkexec-constructor.

That way, we can still use the convenient make-forkexec-constructor
procedure, Shepherd will still be able to manage the process, and people
will be able to find the logs more easily.

What do you think?

> Also, the systemd unit files I've seen use the '--auto-exit' and
> '--hotplug' options.  Do you know if they make sense for us?

These options are interesting, but I don't think they're useful for us
at this time.

Judging by the manual, it looks like the "--auto-exit" option is
intended to be used when a mechanism exists for automatically starting
pcscd on demand (maybe when a user plugs in a security token?), so you
don't need to keep it running all the time.  We don't have a mechanism
like that at this time.

As for the "--hotplug" option, it looks like it's intended to be used to
tell a running pcscd to re-read its configuration file.  However, since
that configuration file is an immutable file in the store, it isn't ever
going to change.

Maybe in the future we can think of helpful ways to use these options,
but for now I think it's OK to omit them.

-- 
Chris

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]