scd rewrites the reader_0.status file with the same content whenever a client
issues a SERIALNO command, which, apparently GPA does to poll for a card, or
maybe just in response to the rewrite in the first place, triggering an endless
loop of 'rewrite' -> 'serialno' -> 'rewrite' ...
In any case, to avoid excessive filewatcher activity, and to break such cycles,
scd should check the current published state and only write the file if the
contents would change as a result.
I see that this is a bit annoying. However I don't see the real problem. GPA
works just fine.
GPA works fine since it's full of sentinels blocking reentrance into the
reloading code, which I assume is triggered by the scdaemon behaviour
described. In addition, GPA causes the whole stack to wake up periodically to
reload data that didn't change. That's not nice for laptop users and
contributes to Global Warming :)
I checked this again and can't replicate this. The file is only written if the
status of the slot changed - independent of any client connection or the use of
SCD SERIALNO. If you lo updating slot 0 status: 0x0000->0x0007 (0->1)ok a the
logs (no options needed) you can clearly see that:
I checked this again and can't replicate this. The file is only written if the
status of the slot changed - independent of any client connection or the use of
SCD SERIALNO. If you look a the logs (no options needed) you can clearly see that:
I checked this again and can't replicate this. The file is only written if the
status of the slot changed - independent of any client connection or the use of
SCD SERIALNO. If you watch the log (no options needed) you can clearly see that:
updating slot 0 status: 0x0000->0x0007 (0->1)
updating slot 0 status: 0x0007->0x0000 (1->2)
updating slot 0 status: 0x0000->0x0002 (2->3)
updating slot 0 status: 0x0002->0x0007 (3->3)
This list the status transitions and the transistions of an internal change
counter. They are triggered by starting scdaemon, inserting and removing the
card and powering up/down the card.
On my system I can't see any background action on scdaemon introduced by GPA.
It does nothing except for reading an event counter from gpg-agent which gets
bumped up by any status change in scdaemon and thus only if the status really
changes.
If you can't figure out why your system behaves different, send me by PM a
combined log of gpg-agent and scdaemon output with debug set to 1024.