Xen devel - May 2007 - PATCH: Add persistent guest & hv logging in xenconsoled

The attached patch adds the persistent logging to the xenconsoled daemon.

  * The  --log  command line argument takes one of 4 values

      - none   - no logging   (the default)
      - hv     - log all hypervisor messages
      - guest  - log all guest messages
      - both   - log all guest & hypervisor messages

  * The --log-dir command line argument takes a path to specify where
    to store logfiles. If omitted it defaults to /var/log/xen/console

  * The hypervisor logfile is $LOGDIR/hypervisor.log

  * The guest logfile is  $LOGDIR/guest-[NAME].log

  * If receiving a SIGHUP it will close & re-open all log files to
    enable logrotate to do its magic

  * Fixes the permissions of /var/run/xenconsoled.pid

  * Adds a --pid-file command line argument to override the default
    location of pid file (this is not really related to logging, but
    since i was in that code...)


  Signed-off-by: Daniel P. Berrange <berrange@redhat.com>


The patch was done against 3.1.0  codebase, but applies against todays
xen-unstable.hg - though I see alot of stuff pending in the staging
tree, hopefully it won''t break it.

There are 2 open questions....

The first is how to configure & pass the --log arg to xenconsoled. In the
upstream xen codebase the various daemons (xenstore, xenconsoled, etc)
are all forked by the tools/misc/xend script (typically in /usr/sbin/xend).
In Fedora we''re intending to ditch this script & just start each
daemon
directly from the init script & thus we can use /etc/sysconfig/xend to
configure the logging args. Solaris also doesn''t use that
tools/misc/xend
script IIRC, having their own scripts for stopping/starting distros. So
in this patch I''ve not made any attempt to provide a way to actually
pass
the --log arg to xenconsoled, leaving such decisions upto the distro
packagers. Any alternate ideas are welcome...

When logging hypervisor data we call xc_readconsolering to fetch the data.
Since we don''t want to log the same data over & over again we have
to tell
it to clear the console. So if you enable hypervisor logging in xenconsoled,
then ''xm dmesg'' will no longer show you any data. Personally I
don''t have
any problem with this, but if there''s a way to reliably consume
hypervisor
logs in an incremental manner without having to clear the data I''m open
to suggestions...

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 31/5/07 22:32, "Daniel P. Berrange" <berrange@redhat.com>
wrote:
> The first is how to configure & pass the --log arg to xenconsoled. In
the
> upstream xen codebase the various daemons (xenstore, xenconsoled, etc)
> are all forked by the tools/misc/xend script (typically in /usr/sbin/xend).
> In Fedora we''re intending to ditch this script & just start
each daemon
> directly from the init script & thus we can use /etc/sysconfig/xend to
> configure the logging args. Solaris also doesn''t use that
tools/misc/xend
> script IIRC, having their own scripts for stopping/starting distros. So
> in this patch I''ve not made any attempt to provide a way to
actually pass
> the --log arg to xenconsoled, leaving such decisions upto the distro
> packagers. Any alternate ideas are welcome...
For guest logging it''d be nice to have the option to specify via
xenstore
where the log file should be written. Then it could be decided per guest by
xend, perhaps via a config file option. Having a blanket option on the
cmdline *as well* as a fallback is okay though. Other useful options would
be max log size (both in terms of max logging to a file, and max buffering
for the pty), again these could be read from xenstore per guest, with a
cmdline-specifiable fallback.
> When logging hypervisor data we call xc_readconsolering to fetch the data.
> Since we don''t want to log the same data over & over again we
have to tell
> it to clear the console. So if you enable hypervisor logging in
xenconsoled,
> then ''xm dmesg'' will no longer show you any data.
Personally I don''t have
> any problem with this, but if there''s a way to reliably consume
hypervisor
> logs in an incremental manner without having to clear the data I''m
open
> to suggestions...
I thought I''d applied a patch to improve this interface, clearly I
haven''t
though. I''ll look into it.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, Jun 01, 2007 at 09:10:36AM +0100, Keir Fraser
wrote:
> On 31/5/07 22:32, "Daniel P. Berrange"
<berrange@redhat.com> wrote:
> 
> > The first is how to configure & pass the --log arg to xenconsoled.
In the
> > upstream xen codebase the various daemons (xenstore, xenconsoled, etc)
> > are all forked by the tools/misc/xend script (typically in
/usr/sbin/xend).
> > In Fedora we''re intending to ditch this script & just
start each daemon
> > directly from the init script & thus we can use
/etc/sysconfig/xend to
> > configure the logging args. Solaris also doesn''t use that
tools/misc/xend
> > script IIRC, having their own scripts for stopping/starting distros.
So
> > in this patch I''ve not made any attempt to provide a way to
actually pass
> > the --log arg to xenconsoled, leaving such decisions upto the distro
> > packagers. Any alternate ideas are welcome...
> 
> For guest logging it''d be nice to have the option to specify via
xenstore
> where the log file should be written. Then it could be decided per guest by
> xend, perhaps via a config file option. Having a blanket option on the
> cmdline *as well* as a fallback is okay though. Other useful options would
> be max log size (both in terms of max logging to a file, and max buffering
> for the pty), again these could be read from xenstore per guest, with a
> cmdline-specifiable fallback.
IMHO getting Xenstore involved in this is needlessly complicating what
ultimately should be a simple problem - just need to decide how to make
XenD pass a suitable argument when starting the daemon.  I have posted
a separate mail describing changes we''re doing in Fedora to the init 
scripts which allow the user to directly customize startup args for any
of the Xen related daemons.

Per guest log file names sounds like rather overkill IMHO and having max 
log sizes is unneccessary because logrotate is already capable of managing
the files being created. eg, a config like

 $ cat /etc/logrotate.d/xenconsoled
 /var/log/xen/console/* {
    notifempty
    missingok
    postrotate
        /bin/kill -HUP `cat /var/run/xenconsoled.pid 2>/dev/null`
1>/dev/null 2>&1 || true
    endscript
 }
> > When logging hypervisor data we call xc_readconsolering to fetch the
data.
> > Since we don''t want to log the same data over & over
again we have to tell
> > it to clear the console. So if you enable hypervisor logging in
xenconsoled,
> > then ''xm dmesg'' will no longer show you any data.
Personally I don''t have
> > any problem with this, but if there''s a way to reliably
consume hypervisor
> > logs in an incremental manner without having to clear the data
I''m open
> > to suggestions...
> 
> I thought I''d applied a patch to improve this interface, clearly I
haven''t
> though. I''ll look into it.
I could be misunderstanding the interface - but it seems that if I
don''t
use the clear flag to xc_readconsolering i''d just get the same data
over
and over.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 1/6/07 14:51, "Daniel P. Berrange" <berrange@redhat.com>
wrote:
>> I thought I''d applied a patch to improve this interface,
clearly I haven''t
>> though. I''ll look into it.
> 
> I could be misunderstanding the interface - but it seems that if I
don''t
> use the clear flag to xc_readconsolering i''d just get the same
data over
> and over.
Yeah, the interface does need changing.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 31/5/07 22:32, "Daniel P. Berrange" <berrange@redhat.com>
wrote:
>   * Adds a --pid-file command line argument to override the default
>     location of pid file (this is not really related to logging, but
>     since i was in that code...)
Applied, thanks. But...

Use of uninitialised local variable pidfile detected by gcc in this patch.
You guys really should consider using -Werror. It''s great. :-)

Also, shouldn''t the writes to log files be non-blocking, and those fds
be
added to the select set when there is data waiting to be written?

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Mon, Jun 04, 2007 at 02:48:25PM +0100, Keir Fraser
wrote:
> On 31/5/07 22:32, "Daniel P. Berrange"
<berrange@redhat.com> wrote:
> 
> >   * Adds a --pid-file command line argument to override the default
> >     location of pid file (this is not really related to logging, but
> >     since i was in that code...)
> 
> Applied, thanks. But...
> 
> Use of uninitialised local variable pidfile detected by gcc in this patch.
> You guys really should consider using -Werror. It''s great. :-)
Opps, we do use -Werror for all formal builds - dunno how that got missed.
> Also, shouldn''t the writes to log files be non-blocking, and those
fds be
> added to the select set when there is data waiting to be written?
IIRC, if you select() on a local file handle it''ll always be shown
writable
so I don''t believe it''ll be any use.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 4/6/07 14:52, "Daniel P. Berrange" <berrange@redhat.com>
wrote:
>> Also, shouldn''t the writes to log files be non-blocking, and
those fds be
>> added to the select set when there is data waiting to be written?
> 
> IIRC, if you select() on a local file handle it''ll always be shown
writable
> so I don''t believe it''ll be any use.
The kernel code appears to agree with you! Fair enough then.

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel