[Samba] Printing eats my CPU

[Franz Sirl]

Note: Resent to list only without attachment

At 16:41 08.07.2002, Gerald Carter wrote:
>On Tue, 2 Jul 2002, Martin Zielinski wrote:
>
> > Hi all,
> > I still have several problems with the printing system.
> >
> > The most critical is, that some drivers seem to cause an infinite RPC loop.
> > I have a KYOCERA Mita KM 4230 KX driver installed. In this moment I can see
> > SPOOLSS_GET_PRINTER and SPOOLSS_GET_PRINTERDATA requests and
> > RPC responses on the net. Stracing the smbd process looks like this:
>
>How many printers do you have on the server?  Just looks like normal
>tdb lookups.

I got the same problem here with the Kyocera FS-9000 KX driver rev 1.7 and 
a single printer share on the server. Occasionally printing wouldn't work 
anymore and some smbd processes did cause high CPU load, so far the only 
measure I found was to delete and recreate all the printing TDB's.

Today it happened again for one colleague and he answered "I fiddled with 
the printer settings, playing with the prolog/epilog sequences". This 
caught my attention and I tried the same from my Win2ksp1 PC. I just 
enabled and disabled the prolog/epilog setting in the driver once, pressed 
OK, and voila! My smbd process did go to high CPU load!

In the logs lines like

[2002/07/26 15:57:57, 0] 
rpc_server/srv_spoolss_nt.c:_spoolss_enumprinterdataex(7935)
   talloc_realloc failed to allocate more memory for data!

arrived quickly. I looked in the source and then added this patch:

-                       DEBUG(0,("talloc_realloc failed to allocate more 
memory for data!\n"));
+                       DEBUG(0,("talloc_realloc failed to allocate more 
memory [data_len=%d] [add_len=%d] for data!\n", data_len, add_l

and then I did a level 10 trace:

[2002/07/26 15:57:57, 9] printing/nt_printing.c:get_a_printer_2(2701)
   Unpacked printer [fs9000] name [\\linuxpc1\fs9000] running driver 
[Kyocera FS-9000 KX]
[2002/07/26 15:57:57, 10] printing/nt_printing.c:get_a_printer(3302)
   get_a_printer: [fs9000] level 2 returning WERR_OK
[2002/07/26 15:57:57, 10] 
rpc_server/srv_spoolss_nt.c:_spoolss_enumprinterdataex(7919)
   retrieved value number [0] [Setup]
[2002/07/26 15:57:57, 10] 
rpc_server/srv_spoolss_nt.c:_spoolss_enumprinterdataex(7919)
   retrieved value number [1] [Render1]
[2002/07/26 15:57:57, 10] 
rpc_server/srv_spoolss_nt.c:_spoolss_enumprinterdataex(7919)
   retrieved value number [2] [PDL1]
[2002/07/26 15:57:57, 10] 
rpc_server/srv_spoolss_nt.c:_spoolss_enumprinterdataex(7919)
   retrieved value number [3] [PDL4]
[2002/07/26 15:57:57, 10] 
rpc_server/srv_spoolss_nt.c:_spoolss_enumprinterdataex(7919)
   retrieved value number [4] [BinReassign]
[2002/07/26 15:57:57, 10] 
rpc_server/srv_spoolss_nt.c:_spoolss_enumprinterdataex(7919)
   retrieved value number [5] [IsUserSetChange]
[2002/07/26 15:57:57, 10] 
rpc_server/srv_spoolss_nt.c:_spoolss_enumprinterdataex(7919)
   retrieved value number [6] [TempKcPrologEpilogData]
[2002/07/26 15:57:57, 0] 
rpc_server/srv_spoolss_nt.c:_spoolss_enumprinterdataex(7935)
   talloc_realloc failed to allocate more memory [data_len=0] [add_len=0] 
for data!

Aha, trying to allocate 0 bytes failed! I have no idea how this RPC stuff 
works, but my guess is that my enabling/of the prolog/epilog sequences 
(TempKcPrologEpilogData?) in the printer driver settings created the entry, 
but since I disabled it immediately again, it wasn't deleted, but set to 0 
length.

Full compressed log attached.

Franz.