From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1foyqF-0006xn-GD for guix-patches@gnu.org; Sun, 12 Aug 2018 18:28:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1foyqA-0002dd-HH for guix-patches@gnu.org; Sun, 12 Aug 2018 18:28:07 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:44085) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1foyqA-0002dX-CZ for guix-patches@gnu.org; Sun, 12 Aug 2018 18:28:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1foyqA-0000Fg-5l for guix-patches@gnu.org; Sun, 12 Aug 2018 18:28:02 -0400 Subject: [bug#32358] Add pcscd service Resent-Message-ID: From: Chris Marusich References: <87a7q2lqc6.fsf@garuda.local.i-did-not-set--mail-host-address--so-tickle-me> <87zhxu7lr9.fsf@gmail.com> Date: Sun, 12 Aug 2018 15:26:47 -0700 In-Reply-To: (Arun Isaac's message of "Sun, 12 Aug 2018 13:55:52 +0530") Message-ID: <87sh3jkyqg.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Arun Isaac Cc: 32358@debbugs.gnu.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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=3D30939 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. Could you make those last couple changes? Everything else looks great! Arun Isaac writes: >> I'm having a little trouble testing this on my system due to the >> following unrelated bug: >> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D28144 >> >> However, I'll keep trying and let you know once I've tested it out. > > Sure, no problem. I was successful in testing it. The service works for me! > I'm ok with adding a system test right now. But, what kind of test? Can > you elaborate on any ideas you have? It would be good to have a system test that verifies that pcscd has successfully started. Even such a simple test would be useful, since it would catch a certain class of problems. There are a lot of existing examples in the gnu/tests directory. I recently added a test like this for the tor service, which you can find here (I haven't committed it to master yet): https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D32346 >>> +(define pcscd-shepherd-service >>> + (match-lambda >>> + (($ pcsc-lite) >>> + (with-imported-modules (source-module-closure >>> + '((gnu build shepherd))) >>> + (shepherd-service >>> + (documentation "PC/SC Smart Card Daemon") >>> + (provision '(pcscd)) >>> + (modules '((gnu build shepherd))) >>> + (start #~(make-forkexec-constructor >>> + (list #$(file-append pcsc-lite "/sbin/pcscd") "-f"))) >>> + (stop #~(make-kill-destructor))))))) >> >> Does this work as written? The make-forkexec-constructor and >> make-kill-destructor procedures are exported in (shepherd service), but >> it doesn't look like that module will be used, since it isn't in the >> modules list. If it does work, then I don't understand how (shepherd >> service) is getting used, so I'd be curious to know why it works! > > Yes, the service does work. But, I don't really know why. I copied this > bit of code from some other service and modified it incrementally until > it did what I wanted. :-P So, I'm not super-clear what exactly is > happening here. I've looked into this. The reason it works is because the "start" field's g-expression is expanded into the Shepherd's configuration file (see: (guix) Shepherd Services), which is evaluated in a context where bindings from the (shepherd service) module are available (see: (shepherd) Invoking shepherd). Therefore, the "start" field's g-expression can use procedures from (shepherd service), such as make-forkexec-constructor, regardless of what is listed in the "modules" field. >>> +(define pcscd-activation >>> + (match-lambda >>> + (($ pcsc-lite usb-drivers) >>> + #~(begin >>> + (use-modules (guix build utils)) >>> + (mkdir-p "/var/lib") >>> + (symlink #$(directory-union >>> + "pcsc" >>> + (map (cut file-append <> "/pcsc") >>> + usb-drivers)) >>> + "/var/lib/pcsc"))))) >> >> What happens if the symlink target already exists? Will this crash the >> init process, or will the system come online and just report an error? >> Some people (such as myself) have already created this directory >> manually, so the directory might exist if they forget to delete it. > > When the symlink already exists, the system reconfigures properly, but > reports an error. You will have to delete your existing /var/lib/pcsc > symlink before reconfiguring. OK. As long as there's a useful error message, that's good! >>> Subject: [PATCH 2/2] gnu: ccid: Move pcsc-lite from inputs to native-in= puts. >> >> Patch 2/2 looks good to me! > > I pushed this patch alone to master. Great! Thank you. I look forward to getting the service itself into master, also! =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAltwtCcACgkQ3UCaFdgi Rp1n8Q/9Fs3+4vsDSMKk5JCyEDPGzPJIMncTzR6Mnh4eQI2XXdmQSFLbqnF8HccM Ff3Gdbi7EVjfUzADrZRP3Xd4GtdTb3bapgDcm/ldaJl97eNyugLwkh1dHSwYHJ8B EHLLX9b7Pl2wOyZwze2aHJgHaUxE/JsbeZskch4+r17so2SPeVmhW0ihKo2xtml4 r+C43vz+elhhttqgBO2I10846qreTpJeGKfJrRKkZHV7wnEcYKrexf7zSDI3GmcK AlFxlc3DkEksJYppTfad57GLFc4st6Vlih9Ct0iL+Z6IIuaS3bE27TCdLIDG3F2g XtjMLSZpmUaGe5UVWnUEhK3Ui1V1wNnA5nvV1wrpI0rE8WTdH1ORfUf/0rPNPGI7 qKcd+WLa5U0cOFx4UzrO+ufTMYpXI4jNOFVfIUFVhwUZhXojEEEmbdohCVNku+J0 G027XLI5erUG6ftccfUWPg67yuemZayDuPcSdL9hmuTAEGuwbYe04hgeWiVuW7OV bQ20hx7YMdouGoZV2g1JUn/46zpFP7W+GEe/Tkl+mideeeIdec+UuXAs5Kbj2AaX dY9/OLsg6nHjsi2W8ZBeX1yyT/glZg1mOiat6/1dLsY/DrpTU6sVKWKDBqW+3ScY 1Cz3/CeTm+rmc/3WdiP5VLwNe2YtJsMe15h5Avgr5T7KoRjMhIc= =QEuC -----END PGP SIGNATURE----- --=-=-=--