Problems with CGI error pipe

[michaelrsweet]

Version: 1.2.2
CUPS.org User: krumboeck

CUPS 1.2.2 on HPUX 11.11 (PA-RISC 64-bit)

Every time I use the CUPS WEB interface I get following error:

I [24/Jul/2006:13:55:34 -0100] Started "/opt/cups/lib/cups/cgi-bin/printers.cgi" (pid=24639)
E [24/Jul/2006:13:55:34 -0100] CUPS-Get-Default client-error-not-found: No default printer
C [24/Jul/2006:13:55:34 -0100] cupsdUpdateCGI: error reading from CGI error pipe - No such file or directory
C [24/Jul/2006:13:55:34 -0100] cupsdUpdateCGI: error reading from CGI error pipe - No such file or directory
C [24/Jul/2006:13:55:34 -0100] cupsdUpdateCGI: error reading from CGI error pipe - No such file or directory
C [24/Jul/2006:13:55:34 -0100] cupsdUpdateCGI: error reading from CGI error pipe - No such file or directory

The interface is useable, but any error messages are omitted.

best regards
Bernd

[michaelrsweet]

CUPS.org User: murdie

Umm, I now have this error with 1.2.2 compiled from source on a Sun E450 with Solaris 8 - see also Ralf Gross' comments in the cups.general forum - articles 8653 and 8654, Jun 02 2006, titled "Bad Listen address..cups.sock + error reading from CGI error pipe".

Jobs I submit from the command line now vanish - nothing appears in any error log file except the "cupsdUpdateCGI: error reading from CGI error pipe" message.

I restarted the scheduler, and all is well again. I think the priority of this bug report should be higher than '2 - Low'; I wouldn't want this to happen to a production system that I ran.

John A. Murdie

[michaelrsweet]

CUPS.org User: krumboeck

Problem with the socket support is only a question of time (see STR #1859).

You are right, the priority should be higher if print jobs get lost (I can't do this change). Maybe I can help to find the problem. --> but I'm a much better system administrator than C developer. ;)

best regards!
Bernd

[michaelrsweet]

CUPS.org User: mike

I'm not able to duplicate the error here.

I'll need a debug2 error_log file (set MaxLogSize to 0 so you don't lose anything) that shows a complete run of the scheduler leading up to the first occurrence of that error. Make sure that you post all feedback through the STR form, as messages to cups.bugs are not automatically added to the STR...

[michaelrsweet]

CUPS.org User: krumboeck

Printing from command line works (at least for me).

@Murdie: I think you should open a new STR for your problem with vanished print jobs.

The error_log shows:
*) Starting scheduler
*) Connecting to the web interface
*) Accessing printers page (I don't have default printer set)
*) Stopping scheduler

[michaelrsweet]

CUPS.org User: murdie

I've been trying for several hours to reproduce this bug with `debug2' debugging on. Although there are several of the:

cupsdUpdateCGI: error reading from CGI error pipe - No such file or directory

messages scattered through the log file, I haven't managed to reproduce the state where this is all the scheduler will log. Whether I'm right that in this state nothing will print at all, I don't know. I think that perhaps the jobs that apparently vanished when the scheduler got itself into the strange state had errors so that nothing would have appeared on the one printer I was sending them to. I restarted the scheduler in a hurry to fix the problem and perhaps didn't experiment enough with it.

[michaelrsweet]

CUPS.org User: mike

I think this error can be ignored; try the attached patch which clears the last system error before updating the stderr pipe and let me know if the problem persists...

[michaelrsweet]

CUPS.org User: krumboeck

No further CGI error messages in the error_log.

Thanks!

best regards
Bernd

[michaelrsweet]

CUPS.org User: murdie

Yes, no more `cupsdUpdateCGI' messages in my error_log either. I hope that this is not just a case of having suppressed the symptom of a deeper bug. Only time will tell; I'll keep watching.

John A. Murdie

[michaelrsweet]

CUPS.org User: mike

No, the problem was that the "errno" variable was not reset to 0 when a successful partial read (not a complete line) was done from the pipe, so the code that reported the error was responding to a previous error handled elsewhere by the scheduler.

[michaelrsweet]

"str1860.patch":

Index: client.c

--- client.c (revision 5776)
+++ client.c (working copy)
@@ -2186,6 +2186,8 @@
int loglevel; /* Log level for message */

• errno = 0;

while ((ptr = cupsdStatBufUpdate(CGIStatusBuffer, &loglevel,
message, sizeof(message))) != NULL)
if (!strchr(CGIStatusBuffer->buffer, '\n'))