Bug 15802 - TOO MANY OPEN FILES when adding printer driver
Summary: TOO MANY OPEN FILES when adding printer driver
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Printing (show other bugs)
Version: 4.19.4
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: printing-maintainers
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-09 13:28 UTC by Peter Koch
Modified: 2025-02-13 21:30 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Koch 2025-02-09 13:28:28 UTC
Samba has a problem when adding printer drivrs via rpcclient when the printer drivers has more than approx 120 driver files.

I noticed that problem when adding a driver for a Canon TM-255 plotter. It has 147 depend files and the command:

> FILES="CNWT10GM.UPD,CNWUO411.DLL,.... 145 more files"
> rpcclient -U Administrator%secret SERV00 -c "adddriver \"Windows x64\" \"Canon TM-255:CNWUOM.DLL:CNWT10GM.XPD:CNWUOMUI.DLL:NULL:NULL:$FILES\""

failes with WERR_APP_INIT_FAILURE.

This is because all spoolss processes are running with a maximal number of open files of 270.

I tried to fix this within the samba source, but I did find the right spot to raise the open files limit.

If I do:

for pid in <list of PIDs of all spoolss procs>; do
  prlimit -n500:16384 -p$pid
done

the problem is temporarily fixed and the above rpcclient command sucessfully adds the driver.

Here's what David Disseldorp wrote on the samba mailing list:

> Hi Peter,
>
> Thanks a lot for your report and follow-up.
> smbd and winbindd already attempt to manually set RLIMIT_NOFILE limits
> based on configuration of "max open files" and "winbind max domain
> connections" respectively. I think it'd make sense to also attempt to
> raise the limit for Samba rpc daemons.
> Would you be able to raise a bugzilla.samba.org ticket for this? That
> should ensure that we don't forget about it.
> 
> Cheers, David

Kind regards

Peter
Comment 1 David Disseldorp 2025-02-10 01:13:51 UTC
There's one aspect I'm a little confused by:
IIRC, the upload/add-driver process normally involves uploading the driver files first to the SMB server prior to calling spoolss AddPrinterDriverEx(), which then does some registration and moves the files to the arch-specific download area via copy_file(). The copy_file() calls appear to be sequential, so I wouldn't have expected a larger number of driver files to change the amount of concurrently open file descriptors. Still, it should be relatively easy to bump the spoolss value regardless.
Comment 2 Samuel Cabrero 2025-02-11 09:39:27 UTC
Peter, could you please check this patch?

https://gitlab.com/samba-team/devel/samba/-/commit/e8a67082b0ee928f39f9f68ae4778c400a8e5c4f

FDs were being accumulated and closed together instead of closed after copying each file.
Comment 3 Peter Koch 2025-02-13 21:30:39 UTC
(In reply to Samuel Cabrero from comment #2)
Thanks for the quick reply. I will try to apply the patch to the source code of our Samba 4.19.4 server. I can do this during out of office hours only so friday late afternoon will be the first opportunity.