I've tried to use the following spoolssd forking configuration, and it seems to eat (or leak) printserver memory: rpc_server:spoolss = external rpc_daemon:spoolssd = fork Attaching three snapshots of "smbcontrol pid pool-usage" of a rapidly growing smbd process, and a valgrind trace. Samba 4.1.7, Ubuntu 12.04 x64.
Created attachment 9889 [details] smbd-10963-1.txt
Created attachment 9890 [details] smbd-10963-2.txt
Created attachment 9891 [details] smbd-10963-3.txt
Created attachment 9892 [details] valgrind-smbd-10164.log
Created attachment 9893 [details] screenshot.png Scary picture from the server monitoring tool :)
Is this a showstopper for 4.2.0?
(In reply to Karolin Seeger from comment #6) I don't believe this is a showstopper. IIUC, the bug is not encountered when the spoolss server runs internally (default configuration).
(In reply to Alex K from comment #5) Thanks for the report and analysis Alex. The graph does indeed look scary, but it'd be good to see a corresponding Y-Axis.
Every line on that grid represents ten percent, so the server goes from 20% to 40% memory consumption before samba is killed and restarted.
(In reply to Alex K from comment #9) How much memory is on the server in this case? I'll start digging through the valgrind and pool-usage stats.
This one has 3Gb of RAM.
This is no regression compared to 4.1. No 4.2.0 blocker.
How many printers are exposed by the printing backend (CUPS, etc.) on the server? How often is the printer inventory changing? From the valgrind output, it looks like the majority of memory was allocated in the lp_add_one_printer() code path, which is called by spoolss via load_printers(). load_printers() is called on spoolss backend initialisation, spoolss child process startup and by the SIGHUP / MSG_SMB_CONF_UPDATED handlers. Since bso#10652 (another one of yours, Alex ;) was fixed, printers are reloaded on client enumeration, so the SIGHUP / MSG_SMB_CONF_UPDATED load_printers() calls are no longer necessary. Still, they should only be calling through to lp_add_one_printer() if the printer share is doesn't exist.
> --- Comment #13 from David Disseldorp <ddiss@suse.de> --- > Still, they should only be calling through to > lp_add_one_printer() if the printer share doesn't exist. Hmm, that doesn't appear to be the case. Attachment#9890 [details] and Attachment#9891 [details] indicate that printer names are allocated multiple times - "harryplottercl3" is present nine times in 9890 and twelve times in 9891.
Created attachment 10594 [details] Patch against 4.1 to avoid reloading printers on SIGHUP or MSG_SMB_CONF_UPDATED @Alex: please test this patch and report back with talloc pool / valgrind numbers.
> How many printers are exposed by the printing backend (CUPS, etc.) on the server? ~200 > How often is the printer inventory changing? Rarely, maybe once a week.
I think this is a duplicate of bug #11740. Please reopen if you can still discover it. *** This bug has been marked as a duplicate of bug 11740 ***