Help Please

[Kenichi Okuyama]

Dear Ulf,

>>>>> "UB" == Ulf Bertilsson <ulf.bertilsson at adcomdata.no> writes:
>> Japan development member pointed out that running Samba as daemons is
>> convenience for controlled by swat etc.., but it isn't recommended
>> because of concerning about performance.
>> 
>> There are some reasons:
>> - inetd is usually optimized with running operating system.
>> - inetd is usually enougth small resources requirements for fork().
>> - master smbd/nmbd (invoked at boot time) always inclease their
>> resources, and become 'fat process.' It causes fork() cost higher.
UB> Any idea what would be the best for non posix systems ?
UB> What would scale best on small 'embeded' systems ?

For embeded systems, there are two cases.

1) You're using unix-like OS, not unix.
  Like VxWare or Phoenix, there are several unix-like os which do
  not support multi-task, but does support multi-thread. In this
  kind of cases, my recommendation is
  "Don't use Samba, at least none of current available."
  This is because Current Samba still have extreame number of
  memory leak, especially when you know that daemon process will
  soon exit(). They simply throw cleanups to OS.
  Fixing this will become extreame works. Sometimes making Yet
  Another Smaller Samba might be of less work.

# One of the reason is that Samba-team is very slow against this
# kind of fix to be patched to original. Even if you find them,
# they'll not be checked until next release, and meanwhile, because
# of functionality addition, your patch does not match anymore.
## This doesn't mean bug is gone. Only, line number changed.


2) You're using unix OS, which is non-POSIX for some reasons.
  Now, okey, you're using unix. The recommendation:
  "use inetd, but be aware of DoS attack"
  (like... by using xinetd).

  Here's reason:
   When you measure speed of turn-arnoud time of connection for
   first time, it is true that on some POSIX os, "smbd -D" reply lot
   faster than using inetd. But, this is not all you have.

   When you use "smbd -D", because smbd -D already contains larger
   amount of stack and heap, all of them have to be copied. If
   you're usign POSIX like os, this will be done by copy-on-modify.
   If you're using non-POSIX, this will be done at fork().
   In ether cases, "smbd -D" require every mapped pages to be
   copied ( except for shared memory and text(program code) ).

   By using inetd, this copy can be reduced. As soon as inetd
   fork() (or vfork()), it will now exec(). Most of the memory space
   will be thrown away and re-allocated. Since smbd is usually running
   in groups, we do not need read "smbd text area" from disk, but
   simply share other smbd process's text area.
   We need to attach new pages for heap and stack, but this amount
   is not as much as that of "smbd -D".

  There are two things we have to keep in mind about inetd.
   1) inetd is weak against DoS attack.
     But usually you use Samba inside firewall, don't you?
     So, this should not be of big problem. If you are worried,
     try xinetd.

   2) we can't control smbd/nmbd like we do with -D.
     If we use "smbd -D", we can easily stop Samba independent from
     other services. usually, all you need is kill top (father) smbd.
     If you use inetd, you first have to change /etc/inetd.conf,
     and send -HUP to inetd, and still you have to kill all the
     smbd/nmbd currently running.

     Easiness of building shell script to do all the above, depends
     strongly on what you have as tool. But this is not what you need
     only for Samba, but for all the other services you run on your
     server too. So, it's usually worth paying cost for building
     one.

---- 
Kenichi Okuyama at Tokyo Research Lab. IBM-Japan, Co.
               @Samba Users Group in Japan