Re: [Xen-changelog] Rewritten XendLogging to not be a singleton class, and not have methods used

Re: [Xen-changelog] Rewritten XendLogging to not be a singleton class, and not have methods used

[Jeremy Katz]

On Mon, 2005-10-10 at 15:32 +0000, Xen patchbot -unstable wrote:
> Log to a temporary file if permission is denied to log
> to /var/log/xend.log, as happens when you are not root.  Fixes bug
> #305. 

This is going to lead to a lot of ugly little files scattered
through /tmp.  Why not fall back to only logging critical problems to
stderr instead of still trying to make sure all of the debug domain
information is output to the log?  

Jeremy

Re: Re: [Xen-changelog] Rewritten XendLogging to not be a singleton class, and not have methods used

[Ewan Mellor]

On Mon, Oct 10, 2005 at 12:02:06PM -0400, Jeremy Katz wrote:

> On Mon, 2005-10-10 at 15:32 +0000, Xen patchbot -unstable wrote:
> > Log to a temporary file if permission is denied to log
> > to /var/log/xend.log, as happens when you are not root.  Fixes bug
> > #305. 
> 
> This is going to lead to a lot of ugly little files scattered
> through /tmp.  Why not fall back to only logging critical problems to
> stderr instead of still trying to make sure all of the debug domain
> information is output to the log?  

That's certainly a possibility, and I'm not keen on having those files in
/tmp, but nor did I like the idea that useful debugging information would be
thrown away, given the fragility of the tools at the moment.

xm help doesn't cause any logging for me, so there's actually no file created.
I don't know why else someone would be running xm as a non-privileged user --
perhaps someone who does so could speak up?

There is actually a configuration option to set the log file, so people who
are using xm regularly in that mode do have the option to set the log file
somewhere that they can write, thus avoiding the small files.

Ewan.

Re: Re: [Xen-changelog] Rewritten XendLogging to not be a singleton class, and not have methods used

[Dan Smith]

EM> xm help doesn't cause any logging for me, so there's actually no
EM> file created.  I don't know why else someone would be running xm
EM> as a non-privileged user -- perhaps someone who does so could
EM> speak up?

I think that xm should be at least able to run "help" and "help
--long" as non-root.  It should definitely be able to do so without a
stack trace.  I don't like blindly running tools as root before I at
least get a chance to look at the help output as a non-root user.

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com

Re: Re: [Xen-changelog] Rewritten XendLogging to not be a singleton class, and not have methods used

[Ewan Mellor]

On Mon, Oct 10, 2005 at 09:44:03AM -0700, Dan Smith wrote:

> 
> EM> xm help doesn't cause any logging for me, so there's actually no
> EM> file created.  I don't know why else someone would be running xm
> EM> as a non-privileged user -- perhaps someone who does so could
> EM> speak up?
> 
> I think that xm should be at least able to run "help" and "help
> --long" as non-root.  It should definitely be able to do so without a
> stack trace.  I don't like blindly running tools as root before I at
> least get a chance to look at the help output as a non-root user.

Sure, and that works now with my fix.  I would have applied your patch, but
what you'd effectively done was moved the import of XendLogging so that it
didn't occur when doing xm help.  That seemed fragile to me, because logging
is something that people will import more or less everywhere, so I've changed
it so that XendLogging can recover from the permission denied without getting
a stack trace.

Cheers,

Ewan.

Re: Re: [Xen-changelog] Rewritten XendLogging to not be a singleton class, and not have methods used

[Dan Smith]

EM> Sure, and that works now with my fix.

Great.  I was really just responding to the question about who might
run xm as non-root :)

EM> I would have applied your patch, but what you'd effectively done
EM> was moved the import of XendLogging so that it didn't occur when
EM> doing xm help.

There was mention a while back about not importing a whole pile of
things to simply run a help command or the like, unless it was
necessary.

I agree with Jeremy that logging inside xm seems a little strange,
especially to the same place as the daemon.  It makes more sense to me
to expect debug information from an interactive tool on the console,
and to see info from a daemon in a log file.  Maybe a command-line or
config-file switch to turn on debug output to stderr?

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@us.ibm.com