Since update to 2.0, I'm not able to print with a local server, as cups client (either from command-line, or from gnome printing subsystem) forces connection to localhost, despite an explicit ServerName directive in ~/.cups/client.conf: [guillaume@beria cauldron]$ strace lpstat -a ... open("/home/guillaume/.cups/client.conf", O_RDONLY) = 5 fcntl(5, F_GETFD) = 0 fcntl(5, F_SETFD, FD_CLOEXEC) = 0 read(5, "ServerName 128.93.58.1\n#ServerNa"..., 4096) = 146 read(5, "", 4096) = 0 close(5) = 0 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 5 setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(5, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0 setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0 fcntl(5, F_SETFD, FD_CLOEXEC) = 0 fcntl(5, F_GETFL) = 0x2 (flags O_RDWR) fcntl(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(5, {sa_family=AF_INET6, sin6_port=htons(631), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINPROGRESS (Operation now in progress) <- first localhost connection attempt, IPv6 fcntl(5, F_SETFL, O_RDWR) = 0 poll([{fd=5, events=POLLIN|POLLOUT}], 1, 250) = 1 ([{fd=5, revents=POLLIN|POLLOUT|POLLERR|POLLHUP}]) getpeername(5, 0x7fff5393dea0, [256]) = -1 ENOTCONN (Transport endpoint is not connected) close(5) = 0 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 5 setsockopt(5, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 setsockopt(5, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0 setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0 fcntl(5, F_SETFD, FD_CLOEXEC) = 0 fcntl(5, F_GETFL) = 0x2 (flags O_RDWR) fcntl(5, F_SETFL, O_RDWR|O_NONBLOCK) = 0 connect(5, {sa_family=AF_INET, sin_port=htons(631), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress) <- second localhost connection attempt, IPv4 fcntl(5, F_SETFL, O_RDWR) = 0 poll([{fd=5, events=POLLIN|POLLOUT}], 1, 250) = 1 ([{fd=5, revents=POLLIN|POLLOUT|POLLERR|POLLHUP}]) getpeername(5, 0x7fff5393dea0, [256]) = -1 ENOTCONN (Transport endpoint is not connected) close(5) = 0 close(-1) = -1 EBADF (Bad file descriptor) Same thing with an explicit server option: [guillaume@beria cauldron]$ LC_ALL=C lpstat -a -h 128.93.58.1 lpstat: Bad file descriptor Reproducible: Steps to Reproduce:
CC: (none) => ennael1Assignee: bugsquad => thierry.vignaud
Please try with 2.0.1
Keywords: (none) => NEEDINFO
I'm using 2.0.1 already.
It looks like there's issue with that from a long time. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521311 Also note that client.conf is deprecated in 2.0.x which may explain that it's less tested. See https://www.cups.org/documentation.php/doc-2.0/man-client.conf.html Can you report the bug upstream at https://www.cups.org/login.php?PAGE=str.php%3FU ? Thabks
The debian bug entry is related to ServerName directive in cups server configuration (cupsd.conf), whereas my own problem is related to cups client configuration. Here is upstream bug report: https://www.cups.org/str.php?L4539+P-1+S-2+C0+I0+E0+Q
URL: (none) => https://www.cups.org/str.php?L4539+P-1+S-2+C0+I0+E0+Q
Additional tests: * serverName directive doesn't work at all * CUPS_SERVER environment variable does work * command-line options order does matter, ie: lpstat -h servername -a queue -> works lpstat -a queue -h servername -> doesn't work This was quite similar to this issue https://www.cups.org/str.php?L4231, as server version is 1.5.3, but using an explicit version in servername directive (servername/version=1.1) doesn't change anything.
Upstream patch available, but quite invasive (targeted at 2.1): https://www.cups.org/str.php?L4528
Keywords: NEEDINFO => Triaged
Whiteboard: (none) => MGA5TOO
Old issue, closing.
Status: NEW => RESOLVEDResolution: (none) => OLD