-
-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CAM left in unusable state after ca_request_close() #1100
Comments
@catalinii what's your opinion on changing this back to using CA_RESET? |
i can confirm the issue |
Yeah changing back to uninitialized state and using CA_RESET should work |
Turns out that closing the socket triggers the logic in the |
Can you enable -v ca when that happens and post the log? |
It happens exceedingly rarely, less than once a month for me. IIRC |
To reproduce this just needs pull and put card to CAM |
Could be related to why things don't work after a CAM reset:
Oddly this (incomplete write) happened to me today at almost the exact same time, and almost exactly 12 hours since minisatip was started (I restart it at 3 AM every night):
|
Actually no, the "another update_pids is in progress skipping" happens regularly, so probably not related |
Aha, but |
Trying this for the time being: const { spawn } = require('child_process')
const Journalctl = require('@seydx/journalctl')
const journalctl = new Journalctl({
unit: 'minisatip',
})
journalctl.on('event', (event) => {
const message = event['MESSAGE']
if (message.includes('incomplete write')) {
console.log(`Received offending log line, restarting: ${message}`)
spawn('systemctl', ['restart', 'minisatip'])
}
}) |
When an incomplete write occurs, the CAM ends up being unusable until minisatip is restarted:
Since v1.2,
ca_request_close()
is called which just closes the CAM socket. Before, a proper reset was issued:The text was updated successfully, but these errors were encountered: