smbwall

Garry J. Garrett garry_garrett at csgsystems.com
Thu Jan 31 15:02:42 GMT 2002


Scott Gifford wrote:
> 
> David Lee <t.d.lee at durham.ac.uk> writes:
> 
[...]
> [...]
> 
> > > As for allocating a pseudo terminal per smb client; again, I'm going
> > > to stick to the flavors of Unix that I know, and pick on Solaris.  Out
> > > of the box, Solaris builds 48 pseudo terminals.  Because sometimes
> > > users use an X-Windows program (such as exceed) to fire of say "xterm"
> > > via "rlogin" or "telnet", etc. (thus "soaking up" 2 pseudo terminals
> > > for one user login), this ends up supporting about 30 users.  Of
> > > course, you can bump this up (to 1024) by editing /etc/systems and
> > > doing a reconfiguration reboot ("boot -r" in Sun lingo).  As someone
> > > mentioned here, they have 800+ smb clients on their system.  You
> > > could easily run out of psuedo terminals if you allocated one per smb
> > > client.  If you had enough smb clients, you could allocate all of
> > > your pseudo terminals for your smb clients and then not have any
> > > left for people to login with.
> >
> > Ah!  here we get to a misunderstanding.  I wasn't anticipating or
> > suggesting using real pseudo-ttys (that phrase sounds weird!).  Rather
> > using some means analogous to pttys, which might be OS-variable.
> 
> Why would it be a problem to ask admins to create additional
> pseudo-ttys or else not use this feature?  On systems with heavy
> interactive user, I have seen upwards of 1000 pseudo-ttys with no ill
> effects.  There's no significant performance penalty for creating many
> of them, either


Again, speaking specifically about Solaris, there is a fixed upper
limit of 1024 pseudo terminals.  It defaults to 48, but you can bump
it up to 1024.  There is no *performance* penalty for increasing the
pseudo terminals.  If I recall correctly, each terminal has a buffer, 
which must exist in RAM (not virtual memory, real live RAM).  Increasing
the number of pseudo terminals has an impact on how much RAM is available
for general processing.  Of course, 1024 x 2K buffer is 2MB.  Back in
the days of 16MB of RAM, that was a tough pill to swallow, but now-a-days
that you buy RAM by the GB, this is probably not so much of an issue.

Never the less, with 1024 being an upper fixed limit to the number of
pseudo terminals (I think this limitation is due to the naming 
conventions), you could easily on a system with a lot of SMB traffic
use up all your pseudo terminals.

The point is not that it's a bad thing to force SysAdmins (if they
want this wall functionality) to allocate more pseudo terminals,
the point is running out of pseudo terminals is a bad thing(tm).
The issue is, even with 1024 pseudo terminals, you can run out.


PS: For those of you who don't get the "(tm)" thing, it was a
running joke on the Great Circle Security Listserv.  We were
going to copyright and trade mark all the truely bad ideas,
then sue anybody that used them, thus forcing them to clean
up their code.  :-)

-- 
-----------------------------------------------------------------------
Garry J. Garrett                                            
CSG Systems, Inc.      ._o             o              __o   
2525 North 117th Ave.    |>           <\            -\<,    
Mailstop 2-A             4    . . .. />   . . .. ...O/ O    
Omaha, NE 68164-3679                                        

CSG Systems  - http://www.csgsystems.com/	
CSG Internal - http://intranet/unixops/		
My Homepage  - http://garrett.no-ip.com:8080/

       ...Professor Plumb, in the DMZ, with the named pipe...

I do not speak in any capacity on behalf of CSG Systems, Inc.
I get into enough trouble speaking for myself.




More information about the samba-technical mailing list