[cod] Multiple COD:UO servers on the same box

[Steven Hartland]

Couple of points:
1. Sticky bit is useless:
Quote "man sticky":
"A special file mode, called the sticky bit (mode S_ISVTX), is used to
indicate special treatment for directories.  It is ignored for regular files"
2. Executable's copied to swap
This is not true for a number of modern OS's inc FreeBSD and linux?
The only one that springs to mind that still does this is Irix but its been
a while since I dug down into this behaviour on OS's other than FreeBSD
so I would be talking crap :P
3. Might want to trim the crap from you posts i.e. the 220 lines at
the bottom :)

    Steve / K

----- Original Message ----- 
  From: Mark J. DeFilippis 
  To: cod at icculus.org 
  Sent: 09 December 2004 12:45
  Subject: Re: [cod] Multiple COD:UO servers on the same box



  You have been getting some excellent advice and wonderful help.
  Was doing great, up until this part here.  (BTW, I also use screen,
  is it more reliable than nohup.  nohup protects against a Hangup signal
  (-15), and there are other signs you wish to protect against. In addition,
  I have seen instances, depending on execution scheduling, where the
  executable WILL receive a HUP signal if you terminate the shell prior
  to it disassociating the controlling terminal from the process. (See nohup(1))
  (In simpler terms, a nohup is simply fork(2)s a child, turns off certain signal
  processing, and then disassociates itself from your shell process, making its
  parent process your shell's parent process which is often process 1 init.

  With regards to copying executables, or using the same code. PLEASE
  use the same executable. You can use a hardlink if on the same filesystem,
  (otherwise a ln will copy the file anyway), or symbolic. I recommend the hard
  link.  In addition, set the sticky bit on the executable.

  This will induce less lag, as the executable is, on execution, copied to swap
  space only once for ALL instances, and not each time it is spawned. In addition
  depending on the number of instances, there is a memory savings.

  Linux will share text pages, however your Heap and Stack will be allocated in a
  separate memory segment.  If a process sharing an executable attempts to
  write said executable, a fork_on_write(2) will be executed. (See vmstat(1))
  Thus, if a single process goes hog wild, it will NOT impact readonly text (aka
  code) (other processes sharing the same readonly text), at all.

  This does not mean if you have a BUG in the code, and one process hits
  it, and goes in to a spin loop it won't impact your other processes. In fact,
  regardless of what you do, if you have that type of bug, the result will be
  the same whether you are running the same code or two executables.

  Loading the text pages in to memory once saves memory, and has NO
  negative impact at all.  I spent much of my early career writing kernel code
  so I know all too often how this works.  (Yes... Multi-threaded link libraries
  especially!)

  But take all the other good stuff people have been providing to you. They
  know their stuff. (Scripts even!  can't get better than that!!)  Keep them coming...
  I just grabbed another Dual P4 3.0, and am migrating off two older single
  pents. I am lazy and given a stub of code.... heck, Ill use it! ;-))


================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to postmaster at multiplay.co.uk.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/cod/attachments/20041209/df566728/attachment.htm>