[cups.general] Broken pipe error when changing printer options on 1.5.4

[Alex Korobkin]

Stucki, I submitted this as http://www.cups.org/str.php?L4210

Try removing Listen .../cups.sock from cupsd.conf as a workaround.

On 23 November 2012 11:09, C. v. Stuckrad <stucki at mi.fu-berlin.de> wrote:

> Alex Korobkin <korobkin+cups at ...> writes:
>
> > I was wrong about 1.5.3, it happens for both versions. Weird thing, when
> I try
> to reproduce it with strace tracing parent cupsd process, admin.cgi works
> perfectly every time. What could cause admin.cgi to exit to early, and why
> wouldn't it do that under strace?
>
>
> Our cups server (debian linux squeeze 64bit Version: 1.5.3-2.4) seemingly
> did
> the same thing. May be after the last updates but nobody noticed the exact
> time.
>
> It was reproducably showing 'broken pipe' (but AFTER correctly(!)
> switching the
> config entry to the new value - we were trying to set a printer to duplex,
> and
> according to the next 'listing' the value changes, even if the menue fails.
>
> As noticed in this thread "strace somehow avoided the error".
>
> As far as I can interpret 'strace'output, cupsd creates a pipe to talk to
> a 'rss
> notifier' program, after admin.cgi does the web-dialogue with the admin.
> This notifier process is eighter dying prematurely or the dialogue results
> in a
> filedescriptor leak leaving a dead pipe. So when the cupsd, always directly
> after sending a debug line containing:
>
> d [Date&Time] sub->pipe=27
> W [Date&Time] Notifier for subscription 28
> (rss:///queue-audit.rss?max_events=20) went away, retrying!
>
> (...cupsde) sends something to the dead descriptor, it gets EPIPE Error.
>
> And depending on the concurrency between 'cupsd', 'admin.cgi' and this 'rss
> notifier', the menue on the admin's screen will either get the real result
> or
> get only 'PIPE BROKEN' whatever comes first in real time.  This is why
> 'strace'
> can influence it (slowing down context switches and catching signals to
> write
> the log, it 'accidentally corrects' the issue). In strace's log you can
> see, tht
> the broken pipe will still happen, but the menue gets it's output first.
>
> BUT how to find out what causes the real problem (descriptor leak?
> asynchronous
> interleaved starts and stops of cgi-bins messing up pipe ends?) somebody
> has to
> analyze the sources and the method of creating/using/inheriting/closing
> pipes.
>
> By opening three different browsers, thus running three different
> admin-sessions
> I could move the dead descriptor from position fd27 to fd30! So may be its
> possible to reproduce it for tests ...
>
> I hope this may help somebody finding out the real issue ..   Stucki
>
>
>
> _______________________________________________
> cups mailing list
> cups at easysw.com
> http://lists.easysw.com/mailman/listinfo/cups
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cups.org/pipermail/cups/attachments/20121123/91d9926c/attachment-0001.html>