Provided by: xmlsysd_2.6.0-0ubuntu5_amd64 bug


       xmlsysd  -  provide  anonymous  information to enable the efficient remote monitoring of a
       network workstations, especially in the context of a beowulf or a LAN subnet.


       xmlsysd [-v] [-d port] [-i port] [-n nconnect]


       The xmlsysd daemon is designed to provide statistics and system information  to  hosts  or
       monitor programs over the network via a simple, easily parsable API.

       In  forking  daemon  mode  ([-d  port])  it listens upon the suggested port (which must be
       unoccupied) and, upon a connection request, accepts it and  forks  a  copy  of  itself  to
       handle the connection.  The connection is not authenticated in any way, but should be safe
       and efficient on a protected cluster like a beowulf or firewall-protected LAN.

       The maximum number of permitted forked daemons/connections can be  set.   ([-n  nconnect],
       default  10).   For  xinetd-based operation, this must be set in /etc/xinetd.d/xmlsysd, as
       xinetd controls the number of permitted connections directly.

       The daemon can be invoked from a command line in verbose mode ([-v 1]) to obtain debugging
       information.   Obviously  this  "breaks" the xml and hence the daemon!  The easiest way to
       debug is to invoke the daemon in inetd mode and verbose set so you can just interact  with
       it  on  the  command line.  Note that verbosity can be set to certain values to "focus" on
       particular subroutines or operations and can be  (re)set  at  the  command  line  via  the
       "verbose" command.

       Note  that  the  port  numbers used in the [-i port] or [-d port] arguments MUST match the
       port numbers used by the client applications.  In the case of at  least  the  accompanying
       wulfstat application, the ports should default to 7887 in xinetd-based daemon and wulfstat
       and can be overridden in the latter in the hostfile.


       Security methodology and requirements vary from site to site, so it  is  not  possible  to
       "preconfigure"  security  for  xmlsysd  except  in the context of a known distribution and
       environment.  xmlsysd has no intrinsic security -- it  will  happily  service  connections
       from  any host.  Although it was written with some care to avoid buffer overwrite attacks,
       it is impossible to guarantee that this care was totally successful.

       It is therefore strongly suggested  that  xmlsysd  be  secured  unless  it  is  run  in  a
       protected/firewalled   environment.    In   daemon   mode,   tcp  wrappers  together  with
       /etc/hosts.[allow,deny] provide a reasonable layer of security.  In xinetd-based operation
       (the  installation  default  in  the  rpm)  one will likely need to use (e.g.) ipchains or
       iptables, which adds kernel overhead but allows access to be  carefully  controlled.   For
       the  truly  paranoid,  although it hasn't been personally tested by me, there is no reason
       that  one  should  not  be  able  to  use  ssl  (stunnel)  or  ssh  (port  forwarding)  to
       bidirectionally  encrypt  daemon traffic over even a WAN and simultaneously provide strong
       host identification.

       In addition, unless one is either debugging or running a private forking daemon wrapped by
       e.g. ssh port forwarding, the daemon should generally be run as a non-privileged user such
       as "guest", and installs itself that way by default.

       NO WARRANTY is provided for the intrinsic security of this  daemon,  and  it  is  best  to
       assume  that  it  contains  an  as-yet-undiscovered  exploit in configuring your system to
       secure it. Use it at your own risk and take whatever measures you deem necessary  to  make
       that level of risk acceptable in your own environment.


       Once a connection is established the daemon accepts many commands:


       Initialize all structures.  REQUIRED to be the first command.

       send Send the currently enabled node/clients statistics.

       sendall Send ALL available (not PID-based) node/client statistics.

       on  flag1 flag2 flag3... (or) all off flag1 flag2 flag3... (or) all Set control flags that
       mask what information is sent by the send command.  The flags currently supported include:

       compress, whitespace,  identity,  time,  users,  cpuinfo,  loadavg,  meminfo,  net,  stat,
       sysvipc, uptime, version, pids, running, root.

       quit Terminates the connection -- the daemon instantiation dies.

       The  data  returned  by  the  daemon  in any non-verbose mode should be an http 1.1 header
       fragment followed by a well-formed xml message  containing  the  encapsulated  statistics.
       This  message  can be parsed with standard tools to extract the field contents for display
       or processing or recording.  Each bottom level statistic should be tagged uniquely with at
       least  an  "id"  identifier  differentiating  multiple interfaces or values with otherwise
       identical tags.

       When writing an interface, remember that the interface may well know  (or  need  to  know)
       only  of  a  subset  of  the  fields  the  daemon  provides.   It should not "break" if it
       encounters unknown fields or if the field it expects is  missing.   The  xmlsysd  is  thus
       continue to be both scalable and extensible independent of the tools that use it.

       Additional  suggestions,  especially  those accompanied by code or patches, are greatfully
       welcomed.  Feel free to include patch authorship in comments within the  patches  --  they
       will be left in the source to immortalize your contributions.  They'll also entitle you to
       tap into the "beverage" clause of the modified GPL but the other way...  I'll  buy  you  a


       The only reliable way to see if a statistic is supported is to crank it up and see what it
       finds.  You can easily do this in userspace -- just enter e.g. xmlsysd  -i  7882  and  the
       daemon  will  start  up.  Enter "init".  You should see the all the non-pid fields.  Enter
       "on pids" and then "send".  You should see all the supported statistics AND at  least  the
       status  information  a  few "running" processes (repeat some more sends sends if necessary
       until you surprise something running).  Nothin' to it.


       Please  send  bug  reports,  patches,  suggestions,  etc.  to   If  the
       suggestions  are  sufficiently  general,  they  may  be worth discussing on the Beowulf or
       Extreme Linux lists, see

       for information on what these projects are and instructions for joining in.


       The author of xmlsysd is Robert G. Brown.  xmlsysd is provided under a  slightly  modified
       GPL  version 2"b" (for beverage), see the README.GPL in the source.  The current source is
       freely available from the author upon request at:

       What's the GPL "b" modification?  He's glad you asked.  If you use the software and happen
       to  meet  the  author  (say,  at  a  Linux Expo or the like) you are morally and ethically
       obligated to at least offer to buy him a beverage, if time and circumstances  permit.   If
       you  are  a  software  distributer/reseller and actually make money from the software, you
       might consider going a bit further and sending the author a bottle of nice, dry  red  wine
       from time to time as a "royalty".  Thank you very much indeed.