SAMBA digest 1822

[Dan Stromberg]

I generally like sun, but sun really blew it on this killall thing. 
They took a standard name for something really useful and made it do
something other than what it should.  Fearing the "don't change it
unless there's a REALLY GOOD reason" ideas at sun, I fear this may never
get fixed now.

ISTR there are some sun folks on this list: Please, sun people, please
fix killall?  It should work like on irix and linux?  It's really going
to confuse irix and linux (and other?) people who move to solaris.

Personally, I wrote my own killall, and tucked it in a directory on my
path ahead of the broken sun one.  But I'm always a little worried
someday my path'll be set wrong, and I'll get a truly weird effect from
running the wrong program.  I'd remove the broken sun one, but I suspect
something depends on it...

Steve Resnick wrote:
> 
> I must object!!!!! killall works fine on some systems (e.g.: Linux) but
> on Solaris, killall does just that --- it kills ALL processes.
> 
> At 10:25 AM 9/25/98 +1000, you wrote:
> >Date: Thu, 24 Sep 1998 14:35:45 +1000
> >From: PayPC System Mail Subscriber <spammail at quanta.paypc.com>
> >To: samba at samba.anu.edu.au
> >Subject: Re: Start and stop the samba server
> >Message-ID: <199809240435.OAA11327 at quanta.paypc.com>
> >
> >
> >> Is there a good way to stop and restart the samba server...
> >> for example to have it re read the smb.conf, without rebooting the
> >> actual pc?
> >>
> >> if I should kill a process should I kill them all ??? if so is there an
> >> efficent way to do this?
> >
> >Heheheh, you guys should read your unix command line help. :)  The command
> >you want is:
> >
> >killall -HUP smbd
> >
> >killall kills (or sends the specified signal) to all exectuables which the
> >specified name.
> >
> >I've never had problems just SIGTERM'ing (no signal specified to
> >kill/killall) smbd's on "live" sessions.  The only problem I'd envisage
> would
> >be with oplocked files (smbstatus is your friend!)....  in which case -HUP
> >would be the preferred technique - though the changes aren't applied to
> >already-established sessions.  It sounds like samba automagically re-reads
> >its smb.conf anyhow; I excerpt from the current samba man page:
> >
> >       The configuration file, and any files  that  it  includes,
> >       are  automatically  reloaded every minute, if they change.
> >       You can force a reload by sending a SIGHUP to the  server.
> >       Reloading  the  configuration file will not affect connec-
> >       tions to any service that is already established.   Either
> >       the user will have to disconnect from the service, or smbd
> >       killed and restarted.
> >
> >So if you have a "dead time" auto-logout (as I do), the changes will be
> >picked up eventually.  If you wish to force an immediate change, than
> >SIGTERMing the sessions is the only way (that is, kill/killall without a
> >specified signal name).
> >
> >Ya know, every time I install/radically alter/remove vital system services
> >from my always-busy intranet server box without having to run for another
> cd,
> >reboot multiple times, or experience any downtime or interruption of service
> >whatsoever, I thank whatever wisdom resides within me which prodded me into
> >deep-sixing my NT4 servers.  (We also manage to get one box to do what
> >required two boxes to perform satisfactorily, and then some.).
> >
> >=Rob=