Summary: | net-print/cups-bjnp-1.0 and net-print/cups-1.6.1: Failed to read side-channel request! | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
Component: | [OLD] Printing | Assignee: | Printing Team <printing> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 463014 |
Description
Martin von Gagern
2012-08-08 21:46:44 UTC
Arg! Seems I had been too tired while I diagnosed this issue. A read returning 0 is an indication of a closed socket. A spurious readiness due to the described bug would have resulted in a return value of -1 combined with a suitable errno of EWOULDBLOCK or EAGAIN. So the question is, why does cupsd close the side-channel socket while its child is still alive? From the cups-bjnp sourceforge page: The version 1.1 adds support for printing over Ipv6 and fixes some bugs (the "failed to read side channel" error message). Version 1.2 only fixes a compilation error. No other fixes Since we only have 1.1 in tree now and this bug was reported against 1.0, I consider this fixed. |