Hello, I am running a SuSE SLES9 Server with samba-3.0.14a, this server is acting only as a printserver. Printing is running well, but after a day I have a lot of IPC$ Sessions, does this share have a important function? I there a timeout for this sessions available? This IPC$-Sessions alway asking my cups-server and it took a high amount of cpu-load. Any help is welcome! regards Franz
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Franz Pf?rtsch wrote:> Hello, > > I am running a SuSE SLES9 Server with samba-3.0.14a, this server is acting > only as a printserver. > > Printing is running well, but after a day I have a lot of IPC$ Sessions, > does this share have a important function? I there a timeout for this > sessions available? > > This IPC$-Sessions alway asking my cups-server and it took a high amount of > cpu-load.[IPC$] is the share that the windows connect to in order to open named pipes in order to issue the spoolss RPC calls. cheers, jerry ====================================================================Alleviating the pain of Windows(tm) ------- http://www.samba.org GnuPG Key ----- http://www.plainjoe.org/gpg_public.asc "There's an anonymous coward in all of us." --anonymous -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDcgbpIR7qMdg1EfYRAvNTAJ45Ch50+o5UAWP01H9fNfoMY28O7wCgyYTL x4L8WTprsV7XVnFo2opnwv8=yvzk -----END PGP SIGNATURE-----
Gerald (Jerry) Carter wrote:> > [IPC$] is the share that the windows connect to in order to > open named pipes in order to issue the spoolss RPC calls. >How could I finish this connections, they took a lot of CPU (30%). Or is it "dangerous" to disrupt them. When I restart the smbd the load is "normal". regards Franz
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Franz Pf?rtsch wrote:> Gerald (Jerry) Carter wrote: > >> [IPC$] is the share that the windows connect to in order to >> open named pipes in order to issue the spoolss RPC calls. >> > How could I finish this connections, they took a lot of CPU (30%). > Or is it "dangerous" to disrupt them. > > When I restart the smbd the load is "normal".You need to look at the traffic to know for sure what is going on. The connection to IPC$ itself is not taking CPU. It the chatter from the client that is consuming CPU. Listen to the client using ethereal and find out what she is saying. cheers, jerry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDch+oIR7qMdg1EfYRAoAIAJ0dMV6jySaYcXfCw0UEZ6gpJke5MACeLGZ7 cCP/ryIS0w9VnsHFkxywBuY=VUQ1 -----END PGP SIGNATURE-----
I made a top and saw the cupsd is consuming the CPU.
In my opinion the IPC$ is asking about printers!
here a snipped of my smb.conf
---8<------------------
global]
unix charset = LOCALE
workgroup = BROSE
realm = BROSE.NET
server string = %h Samba %v
interfaces = 127.0.0.1, eth1
bind interfaces only = Yes
security = ADS
username map = /etc/samba/smbusers
use kerberos keytab = Yes
log level = 1
log file = /var/log/samba/log.%m
socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
printcap cache time = 120
# name resolve order = host wins bcast
hostname lookups = Yes
preferred master = No
local master = No
domain master = No
wins server = brose.net
ldap ssl = no
idmap uid = 10000-90000
idmap gid = 10000-90000
winbind separator = +
printer admin = @BROSE+COB_CUPS_Printer_Admin
---8<------------------
First I set the "printcap cache time" to 60 and I had a "peek
CPU" of 50 %.
Then I changed to 120 and now the "peek CPU" has a value of 30 %
There are 89 printqueues at cups defined.
Is there no chaching mechanism?
regards
Franz
>
> You need to look at the traffic to know for sure what
> is going on. The connection to IPC$ itself is not taking
> CPU. It the chatter from the client that is consuming CPU.
> Listen to the client using ethereal and find out what she
> is saying.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Franz Pf?rtsch wrote:> I made a top and saw the cupsd is consuming the CPU. > > In my opinion the IPC$ is asking about printers! > > First I set the "printcap cache time" to 60 and I had a "peek CPU" of 50 %. > Then I changed to 120 and now the "peek CPU" has a value of 30 %Printcap cache time defaults to 12.5 minutes in current releases. What version are you running? cheers, jerry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDck1ZIR7qMdg1EfYRAkGiAJ47ioJHFIsF+UfDIFWyr7uxQyFRPgCePESB vLBBdxV/UhEY3K0LH7QhQaU=mN1E -----END PGP SIGNATURE-----
Thanks for help. I am using SuSE SLES9 samba-3.0.14a. the precompiled value is 0. I setted the value to 360. Can you explain the differend values? I created one printer and the printer was immediately visible at the windows-explorer? regards and thanks for help Franz> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Printcap cache time defaults to 12.5 minutes in current releases. > What version are you running?
Franz Pf?rtsch wrote:> Gerald (Jerry) Carter wrote: > > >>[IPC$] is the share that the windows connect to in order to >>open named pipes in order to issue the spoolss RPC calls. >> > > How could I finish this connections, they took a lot of CPU (30%). > Or is it "dangerous" to disrupt them. > > When I restart the smbd the load is "normal". > > regards > Franz >Hello! I think, what you are seeing is the same that I reported some time ago. When you open a printer connection to the samba server as "printeradmin", the IPC$ connection is closed after a short time by the windows client (this is a spoolss pipe). When you open a printer connection (means: open the printer window or print) as "normal" user - the connection is held open forever. No idea, why this is. But the connection is definitly not closed by the client. If this is a problem on your system (as is on mine), you might have to close this remaining connection manually. I do this in conn.c / conn_idle_all(). But there might really be more elegant ways... Bye, Martin -- Martin Zielinski mz@seh.de Software Development SEH Computertechnik GmbH www.seh.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Zielinski wrote: | If this is a problem on your system (as is on mine), you | might have to close this remaining connection manually. | | I do this in conn.c / conn_idle_all(). But there might | really be more elegant ways... I recently found a regression in the 3.0 code when compared against 2.2 that connections were not being considered idle when there was a pipe open. The next release will mark connections with a pipe open but no rpc handle open as idle. This might help your situation. cheers, jerry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDc0gCIR7qMdg1EfYRAsrfAJ9Nps/v0AdwOcxBYqiQ8KvjaXsV+gCgzxkt d0qoTkyt4xj55sQEUIAYDfA=nQHo -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Franz Pf?rtsch wrote: | Thanks for help. | | I am using SuSE SLES9 samba-3.0.14a. | | the precompiled value is 0. | I setted the value to 360. | | Can you explain the differend values? | I created one printer and the printer was | immediately visible at the windows-explorer? The printcap cache time defines an interval in seconds after which smbd will look for any new or removed printers. You have a couple of possibilities here. You can manually define each printer in smb.conf (and remove [printers]) or you can seet "printcap name = /etc/printcap" to use the cupsd generated file. The problem is more that the cupsd daemon appears to be quite slow when we try to validate a large number of printer names. Michael, Is there a better way to get cupsd to validate a printer name or something that could be tweaked to speed it up? We can change the Samba code if we are doing something wrong. I think it is currently still close to your original code. cheers, jerry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDc0lOIR7qMdg1EfYRAnENAKDFoI4Ahsh5TpK55vnRPWvtVfyazwCfSO3d VefEQ53A/8ol8y8gPZbTMGk=k0D3 -----END PGP SIGNATURE-----