Stucki, I submitted this as <a href="http://www.cups.org/str.php?L4210">http://www.cups.org/str.php?L4210</a><div><br></div><div>Try removing Listen .../cups.sock from cupsd.conf as a workaround. <br><br><div class="gmail_quote">

On 23 November 2012 11:09, C. v. Stuckrad <span dir="ltr"><<a href="mailto:stucki@mi.fu-berlin.de" target="_blank">stucki@mi.fu-berlin.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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