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

[C. v. Stuckrad]

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