currently printcap reload is being done by every clients' smbd on its own. printcap reload isn't expensive when printcap is a file but it is quite expensive when printcap = cups is set. With 100 connected clients or more printcap reload is putting too much load on the CUPS server. Even a high printcap timeout does not help because printcap is being reloaded immediately when smbd gets a HUP signal or then smb.conf was rewritten. As a fix the printcap reload should probably be done by the forked smbd which currently also handles print queue polling.
Jeremy, you took the bug. Any news on this?
Errr, no sorry. This is a little tricky to do, as any change in the printer list would need to be passed back to the smbd's so they can update any dynamic shares. Jeremy.
Too late for enhancements for 3.5. Raising version.
simo, I think you just fixed this with the aproach of the tdb cache, right?
Not in 3.6.0 - code is still only in master, so currently targetted for 4.0.0 only. Jeremy.
reassign to me. Note: lp_printcap_timeout needs to be used ...
If I'm not mistaken printcap reload is done now in 3.6 by just one background process, correct ?
(In reply to comment #7) > If I'm not mistaken printcap reload is done now in 3.6 by just one background > process, correct ? Yes, the parent smbd process pulls new printer_list.tdb values from cups on printcap cache time expiry, on completion it pushes a MSG_PRINTER_PCAP message to all child smbds. The children then pull the new info out of printer_list.tdb and update their printer state accordingly. This bug can be closed IMO.
thanks! closing it now ...