SAMBA digest 1822
strombrg at nis.acs.uci.edu
Fri Sep 25 20:36:33 GMT 1998
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
> >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
> >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.).
More information about the samba