You are not logged in.
Recently I have problem with CUPS, probably again some kind of regression. I have a network printer (based on raspberry pi) on socket://ip:9100 in raw mode. The printer is working correctly. However, the CUPS from my arch machine is broken. This could be related to recent problems with CUPS filter failed (ghostscript). I try some debugging and even set simple socket in raw mode on my machine to debug.
# setup simple raw server
$ unbuffer nc -l -p 9100 | hexdump -C
Then I printed into it from CUPS At old CUPS from my raspberry pi everything is OK. That means it prints data that should be sent to printer and it disconnects. From Arch however, data is transmitted correctly and then it hangs (processes socket, foomatic-rip, pdf2ps, gs are hanging in the system) without disconnecting. I have been googling if someone has the same problem, but probably it is a recent thing.
Offline
Ok, I was doing some research and find out that the problem is foomatic-rip from cups-filters. What is curious that downgrade doesn't
help... probably deeper dependency (I wasn't using my printer for a while). Then I find out that indeed there are others with
similar problem
https://github.com/OpenPrinting/cups-filters/issues/58
https://github.com/apple/cups/issues/5396
Meantime I will try to find out some workaround ...
Offline
At last I think I got it. This was quite nasty bug to track at least for me (3 days). The problem seems to be a recent upgrade of glibc. There seems to be some changes how stdio handle the stdin. Put it simply if I execute the following code
#include <stdio.h>
#include <unistd.h>
void main(void)
{
FILE *f;
int c;
f = fopen("/etc/issue","r");
dup2(fileno(f),fileno(stdin));
while( (c=fgetc(stdin)) != EOF)
printf("%c",c);
fclose(f);
f = fopen("/etc/issue","r");
dup2(fileno(f),fileno(stdin));
while( (c=fgetc(stdin)) != EOF)
printf("%c",c);
fclose(f);
}
Then in glibc 2.28 a get only one line output on old Debian box as expected two lines. The problem is the combine code of 'stdio' and 'syscalls'. The easy workaround which solve the problem for me at least is the following patch
diff -Naur a/filter/foomatic-rip/foomaticrip.c b/filter/foomatic-rip/foomaticrip.c
--- a/filter/foomatic-rip/foomaticrip.c 2018-08-20 22:48:20.000000000 +0200
+++ b/filter/foomatic-rip/foomaticrip.c 2018-09-11 20:08:09.542690450 +0200
@@ -585,7 +585,7 @@
jobhasjcl = 1;
write_output(buf, startpos);
}*/
- if (file != stdin)
+ /*if (file != stdin)*/
rewind(file);
if (convert) pdfconvertedtops = 0;
That rewinds the 'stdin' handle (descriptor). However I think the real solution should be to get rid of the ugly combination of dup2 and stdio. Which could prevent the problem in the future, but require a little more work ...
Offline
Hi.
Ive had a similar problem but using the foo2zjs-nightly package. using a hp 1018 printer
ive been been hunting for a solution for over 3 weeks. thanks for documenting this!!
Offline
I'm glad it is helpful. The issue is posted on the cups-filters github https://github.com/OpenPrinting/cups-filters/issues/58. However, I don't know how much time it will take them to find out the suitable solution. For the time being I created aur package with the patch - https://aur.archlinux.org/packages/cups … s-patched/
Offline
i posted https://bugs.archlinux.org/task/60044
so that the package maintainer can know of this. Please comment there if you think additional info is needed.
Offline
@0xjmz
Your patch solved the same problem I had with an OKI C3200 printer
but I first had to remove cups-filters
sudo pacman -Rvdd cups-filters
Then I was abel to install
https://aur.archlinux.org/packages/cups … s-patched/
Thank you very much!
Offline
Soon there will be no need for the patched version. The next release of cups-filters will fix the issue.
Offline