Bug 10583 - Memory leaks in spoolssd fork mode
Summary: Memory leaks in spoolssd fork mode
Status: RESOLVED DUPLICATE of bug 11740
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Printing (show other bugs)
Version: 4.1.7
Hardware: All All
: P5 normal (vote)
Target Milestone: 4.3
Assignee: David Disseldorp
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-02 16:16 UTC by Alex K
Modified: 2016-11-16 16:24 UTC (History)
2 users (show)

See Also:


Attachments
valgrind-smbd-10164.log (3.52 MB, text/plain)
2014-05-02 16:17 UTC, Alex K
no flags Details
screenshot.png (20.67 KB, image/png)
2014-05-02 16:18 UTC, Alex K
no flags Details
Patch against 4.1 to avoid reloading printers on SIGHUP or MSG_SMB_CONF_UPDATED (1.31 KB, patch)
2015-01-08 14:49 UTC, David Disseldorp
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex K 2014-05-02 16:16:13 UTC
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.
Comment 1 Alex K 2014-05-02 16:16:37 UTC
Created attachment 9889 [details]
smbd-10963-1.txt
Comment 2 Alex K 2014-05-02 16:16:59 UTC
Created attachment 9890 [details]
smbd-10963-2.txt
Comment 3 Alex K 2014-05-02 16:17:12 UTC
Created attachment 9891 [details]
smbd-10963-3.txt
Comment 4 Alex K 2014-05-02 16:17:36 UTC
Created attachment 9892 [details]
valgrind-smbd-10164.log
Comment 5 Alex K 2014-05-02 16:18:22 UTC
Created attachment 9893 [details]
screenshot.png

Scary picture from the server monitoring tool :)
Comment 6 Karolin Seeger 2014-11-27 10:57:04 UTC
Is this a showstopper for 4.2.0?
Comment 7 David Disseldorp 2014-11-27 11:01:50 UTC
(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).
Comment 8 David Disseldorp 2014-11-27 11:03:02 UTC
(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.
Comment 9 Alex K 2014-11-27 11:10:56 UTC
Every line on that grid represents ten percent, so the server goes from 20% to 40% memory consumption before samba is killed and restarted.
Comment 10 David Disseldorp 2014-11-27 11:19:54 UTC
(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.
Comment 11 Alex K 2014-11-27 18:17:37 UTC
This one has 3Gb of RAM.
Comment 12 Stefan Metzmacher 2014-11-29 10:27:32 UTC
This is no regression compared to 4.1.
No 4.2.0 blocker.
Comment 13 David Disseldorp 2015-01-08 14:19:21 UTC
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 14 David Disseldorp 2015-01-08 14:43:20 UTC
> --- 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.
Comment 15 David Disseldorp 2015-01-08 14:49:41 UTC
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.
Comment 16 Alex K 2015-01-08 15:59:35 UTC
> 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.
Comment 17 Andreas Schneider 2016-11-16 16:24:22 UTC
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 ***