[openib-general] [PATCH] opensm: truncate log file when fs is overflowed

Hal Rosenstock halr at voltaire.com
Tue Aug 29 15:54:42 PDT 2006


On Tue, 2006-08-29 at 18:25, Doug Ledford wrote:
> On Tue, 2006-08-29 at 15:13 -0400, Hal Rosenstock wrote:
> > On Tue, 2006-08-29 at 11:21, Greg Lindahl wrote:
> > > On Sun, Aug 27, 2006 at 06:28:06PM -0400, Doug Ledford wrote:
> > > 
> > > > I would definitely put the option in, and in fact would default it to
> > > > *NOT* truncate.
> > > 
> > > I agree. I have never seen any other daemon with a logfile do this,
> > > why are we out to surprise the admin? The admin might want the start
> > > of the long instead of the end. And so on.
> > 
> > I agree too but there is perhaps a difference here per degree: OpenSM
> > can spew copious logging and fill /var/log readily.
> 
> In which case the -L option to limit the maximum log file size makes
> sense (as does making sure that the default logging level is warnings
> and above, not all sorts of informational stuff unless requested in
> order to keep logs more manageable under normal circumstances).
> 
> In response to another statement made in another email, for better or
> worse, OpenSM *is* a system daemon at this point.  If you don't have (or
> elect not to use) a switch embedded SM, then OpenSM is necessary to keep
> your fabric operational.
> 
> Or to put it another way: if you need to start it during init for your
> system to operate properly, and if it needs to keep running all the
> time, and if you need elevated permissions to run it, and if it has an
> init script...you get the point...the rest of the world is going to tell
> you this is a system daemon with console capabilities, not a console
> program with daemon capabilities.  As such, always thinking of it from
> the perspective of a daemon would be wise in terms of avoiding
> surprising users down the road IMO.

Well stated and I concur with that viewpoint.

I may be mistaken but I think Sasha may have been referring to some
things that could/might be done to make it behave better as a daemon.

-- Hal





More information about the general mailing list