guix-patches
[Top][All Lists]
Advanced

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

[bug#32358] Add pcscd service


From: Clément Lassieur
Subject: [bug#32358] Add pcscd service
Date: Mon, 13 Aug 2018 18:21:33 +0200
User-agent: mu4e 1.0; emacs 26.1

Chris Marusich <address@hidden> writes:

> 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.

When using MAKE-FORKEXEC-CONSTRUCTOR, yes.  And it makes sense only for
blocking processes, because they are 'dumb', they don't return
information about whether they have succesfully started or not.
However, 'pcscd' is smart, it does return '1' if it failed to start, and
'0' if it started successfully.  So, all the logic (the pid check and
everything) is done within 'pcscd' itself, no need for the Shepherd to
do it.

(start (pid-of smart-nonblocking-process)) == (start (make-forkexec-constructor 
dumb-blocking-process))

> However, I don't know if Shepherd uses that PID file for anything else
> while managing the process later on.

No, it doesn't use the #:PID-FILE argument for anything else.  However,
it does use the return value of the start procedure as a PID file to
automatically respawn the service if it's an integer.  So you just need
to return (call-with-input-file pid-file read) instead of #t if you want
automatic respawning, as in
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=fdbca05d78d091bfc075e54c9fb90125262eadf0.

> 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.

All this stuff is done by 'pcscd' when run without '-f', using
MAKE-FORKEXEC-CONSTRUCTOR doesn't help in any way.  Moreover, we do lose
the 'syslog' feature if we use it.

> 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?

I think it's better to use syslog ;-)  By the way, 'syslogd' should be
added as a requirement I 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?

[...]

> 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.

Ok!

Clément





reply via email to

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