src/collectd-python.pod

   1 # Permission is hereby granted, free of charge, to any person obtaining a
   2 # copy of this software and associated documentation files (the "Software"),
   3 # to deal in the Software without restriction, including without limitation
   4 # the rights to use, copy, modify, merge, publish, distribute, sublicense,
   5 # and/or sell copies of the Software, and to permit persons to whom the
   6 # Software is furnished to do so, subject to the following conditions:
   7 #
   8 # The above copyright notice and this permission notice shall be included in
   9 # all copies or substantial portions of the Software.
  10
  11 =encoding UTF-8
  12
  13 =head1 NAME
  14
  15 collectd-python - Documentation of collectd's C<python plugin>
  16
  17 =head1 SYNOPSIS
  18
  19   LoadPlugin python
  20   # ...
  21   <Plugin python>
  22     ModulePath "/path/to/your/python/modules"
  23     LogTraces true
  24     Interactive false
  25     Import "spam"
  26
  27     <Module spam>
  28       spam "wonderful" "lovely"
  29     </Module>
  30   </Plugin>
  31
  32 =head1 DESCRIPTION
  33
  34 The C<python plugin> embeds a Python-interpreter into collectd and provides an
  35 interface to collectd's plugin system. This makes it possible to write plugins
  36 for collectd in Python. This is a lot more efficient than executing a
  37 Python-script every time you want to read a value with the C<exec plugin> (see
  38 L<collectd-exec(5)>) and provides a lot more functionality, too.
  39
  40 The minimum required Python version is I<2.3>.
  41
  42 =head1 CONFIGURATION
  43
  44 =over 4
  45
  46 =item B<LoadPlugin> I<Plugin>
  47
  48 Loads the Python plugin I<Plugin>.
  49
  50 =item B<Encoding> I<Name>
  51
  52 The default encoding for Unicode objects you pass to collectd. If you omit this
  53 option it will default to B<ascii> on I<Python 2> and B<utf-8> on I<Python 3>.
  54 This is hardcoded in Python and will ignore everything else, including your
  55 locale.
  56
  57 =item B<ModulePath> I<Name>
  58
  59 Appends I<Name> to B<sys.path>. You won't be able to import any scripts you
  60 wrote unless they are located in one of the directories in this list. Please
  61 note that it only has effect on plugins loaded after this option. You can
  62 use multiple B<ModulePath> lines to add more than one directory.
  63
  64 =item B<LogTraces> I<bool>
  65
  66 If a Python script throws an exception it will be logged by collectd with the
  67 name of the exception and the message. If you set this option to true it will
  68 also log the full stacktrace just like the default output of an interactive
  69 Python interpreter. This should probably be set to false most of the time but
  70 is very useful for development and debugging of new modules.
  71
  72 =item B<Interactive> I<bool>
  73
  74 This option will cause the module to launch an interactive Python interpreter
  75 that reads from and writes to the terminal. Note that collectd will terminate
  76 right after starting up if you try to run it as a daemon while this option is
  77 enabled so make sure to start collectd with the B<-f> option.
  78
  79 The B<collectd> module is I<not> imported into the interpreter's globals. You
  80 have to do it manually. Be sure to read the help text of the module, it can be
  81 used as a reference guide during coding.
  82
  83 This interactive session will behave slightly differently from a daemonized
  84 collectd script as well as from a normal Python interpreter:
  85
  86 =over 4
  87
  88 =item *
  89
  90 B<1.> collectd will try to import the B<readline> module to give you a decent
  91 way of entering your commands. The daemonized collectd won't do that.
  92
  93 =item *
  94
  95 B<2.> collectd will block I<SIGINT>. Pressing I<Ctrl+C> will usually cause
  96 collectd to shut down. This would be problematic in an interactive session,
  97 therefore this signal will be blocked. You can still use it to interrupt
  98 syscalls like sleep and pause but it won't generate a I<KeyboardInterrupt>
  99 exception either.
 100
 101 To quit collectd send I<EOF> (press I<Ctrl+D> at the beginning of a new line).
 102
 103 =item *
 104
 105 B<3.> collectd handles I<SIGCHLD>. This means that Python won't be able to
 106 determine the return code of spawned processes with system(), popen() and
 107 subprocess. This will result in Python not using external programs like less
 108 to display help texts. You can override this behavior with the B<PAGER>
 109 environment variable, e.g. I<export PAGER=less> before starting collectd.
 110 Depending on your version of Python this might or might not result in an
 111 B<OSError> exception which can be ignored.
 112
 113 If you really need to spawn new processes from Python you can register an init
 114 callback and reset the action for SIGCHLD to the default behavior. Please note
 115 that this I<will> break the exec plugin. Do not even load the exec plugin if
 116 you intend to do this!
 117
 118 There is an example script located in B<contrib/python/getsigchld.py>  to do
 119 this. If you import this from I<collectd.conf> SIGCHLD will be handled
 120 normally and spawning processes from Python will work as intended.
 121
 122 =back
 123
 124 =item E<lt>B<Module> I<Name>E<gt> block
 125
 126 This block may be used to pass on configuration settings to a Python module.
 127 The configuration is converted into an instance of the B<Config> class which is
 128 passed to the registered configuration callback. See below for details about
 129 the B<Config> class and how to register callbacks.
 130
 131 The I<name> identifies the callback.
 132
 133 =back
 134
 135 =head1 STRINGS
 136
 137 There are a lot of places where strings are sent from collectd to Python and
 138 from Python to collectd. How exactly this works depends on whether byte or
 139 unicode strings or Python2 or Python3 are used.
 140
 141 Python2 has I<str>, which is just bytes, and I<unicode>. Python3 has I<str>,
 142 which is a unicode object, and I<bytes>.
 143
 144 When passing strings from Python to collectd all of these object are supported
 145 in all places, however I<str> should be used if possible. These strings must
 146 not contain a NUL byte. Ignoring this will result in a I<TypeError> exception.
 147 If a byte string was used it will be used as is by collectd. If a unicode
 148 object was used it will be encoded using the default encoding (see above). If
 149 this is not possible Python will raise a I<UnicodeEncodeError> exception.
 150
 151 When passing strings from collectd to Python the behavior depends on the
 152 Python version used. Python2 will always receive a I<str> object. Python3 will
 153 usually receive a I<str> object as well, however the original string will be
 154 decoded to unicode using the default encoding. If this fails because the
 155 string is not a valid sequence for this encoding a I<bytes> object will be
 156 returned instead.
 157
 158 =head1 WRITING YOUR OWN PLUGINS
 159
 160 Writing your own plugins is quite simple. collectd manages plugins by means of
 161 B<dispatch functions> which call the appropriate B<callback functions>
 162 registered by the plugins. Any plugin basically consists of the implementation
 163 of these callback functions and initializing code which registers the
 164 functions with collectd. See the section "EXAMPLES" below for a really basic
 165 example. The following types of B<callback functions> are known to collectd
 166 (all of them are optional):
 167
 168 =over 4
 169
 170 =item configuration functions
 171
 172 These are called during configuration if an appropriate
 173 B<Module> block has been encountered. It is called once for each B<Module>
 174 block which matches the name of the callback as provided with the
 175 B<register_config> method - see below.
 176
 177 Python thread support has not been initialized at this point so do not use any
 178 threading functions here!
 179
 180 =item init functions
 181
 182 These are called once after loading the module and before any
 183 calls to the read and write functions. It should be used to initialize the
 184 internal state of the plugin (e.E<nbsp>g. open sockets, ...). This is the
 185 earliest point where you may use threads.
 186
 187 =item read functions
 188
 189 These are used to collect the actual data. It is called once
 190 per interval (see the B<Interval> configuration option of collectd). Usually
 191 it will call B<plugin_dispatch_values> to dispatch the values to collectd
 192 which will pass them on to all registered B<write functions>. If this function
 193 throws any kind of exception the plugin will be skipped for an increasing
 194 amount of time until it returns normally again.
 195
 196 =item write functions
 197
 198 These are used to write the dispatched values. It is called
 199 once for every value that was dispatched by any plugin.
 200
 201 =item flush functions
 202
 203 These are used to flush internal caches of plugins. It is
 204 usually triggered by the user only. Any plugin which caches data before
 205 writing it to disk should provide this kind of callback function.
 206
 207 =item log functions
 208
 209 These are used to pass messages of plugins or the daemon itself
 210 to the user.
 211
 212 =item notification function
 213
 214 These are used to act upon notifications. In general, a
 215 notification is a status message that may be associated with a data instance.
 216 Usually, a notification is generated by the daemon if a configured threshold
 217 has been exceeded (see the section "THRESHOLD CONFIGURATION" in
 218 L<collectd.conf(5)> for more details), but any plugin may dispatch
 219 notifications as well.
 220
 221 =item shutdown functions
 222
 223 These are called once before the daemon shuts down. It should
 224 be used to clean up the plugin (e.g. close sockets, ...).
 225
 226 =back
 227
 228 Any function (except log functions) may throw an exception in case of
 229 errors. The exception will be passed on to the user using collectd's logging
 230 mechanism. If a log callback throws an exception it will be printed to standard
 231 error instead.
 232
 233 See the documentation of the various B<register_> methods in the section
 234 "FUNCTIONS" below for the number and types of arguments passed to each
 235 B<callback function>. This section also explains how to register B<callback
 236 functions> with collectd.
 237
 238 To enable a module, copy it to a place where Python can find it (i.E<nbsp>e. a
 239 directory listed in B<sys.path>) just as any other Python plugin and add
 240 an appropriate B<Import> option to the configuration file. After restarting
 241 collectd you're done.
 242
 243 =head1 CLASSES
 244
 245 The following complex types are used to pass values between the Python plugin
 246 and collectd:
 247
 248 =head2 Signed
 249
 250 The Signed class is just a long. It has all its methods and behaves exactly
 251 like any other long object. It is used to indicate if an integer was or should
 252 be stored as a signed or unsigned integer object.
 253
 254  class Signed(long)
 255
 256 This is a long by another name. Use it in meta data dicts
 257 to choose the way it is stored in the meta data.
 258
 259 =head2 Unsigned
 260
 261 The Unsigned class is just a long. It has all its methods and behaves exactly
 262 like any other long object. It is used to indicate if an integer was or should
 263 be stored as a signed or unsigned integer object.
 264
 265  class Unsigned(long)
 266
 267 This is a long by another name. Use it in meta data dicts
 268 to choose the way it is stored in the meta data.
 269
 270 =head2 Config
 271
 272 The Config class is an object which keeps the information provided in the
 273 configuration file. The sequence of children keeps one entry for each
 274 configuration option. Each such entry is another Config instance, which
 275 may nest further if nested blocks are used.
 276
 277  class Config(object)
 278
 279 This represents a piece of collectd's config file. It is passed to scripts with
 280 config callbacks (see B<register_config>) and is of little use if created
 281 somewhere else.
 282
 283 It has no methods beyond the bare minimum and only exists for its data members.
 284
 285 Data descriptors defined here:
 286
 287 =over 4
 288
 289 =item parent
 290
 291 This represents the parent of this node. On the root node
 292 of the config tree it will be None.
 293
 294 =item key
 295
 296 This is the keyword of this item, i.e. the first word of any given line in the
 297 config file. It will always be a string.
 298
 299 =item values
 300
 301 This is a tuple (which might be empty) of all value, i.e. words following the
 302 keyword in any given line in the config file.
 303
 304 Every item in this tuple will be either a string, a float or a boolean,
 305 depending on the contents of the configuration file.
 306
 307 =item children
 308
 309 This is a tuple of child nodes. For most nodes this will be empty. If this node
 310 represents a block instead of a single line of the config file it will contain
 311 all nodes in this block.
 312
 313 =back
 314
 315 =head2 PluginData
 316
 317 This should not be used directly but it is the base class for both Values and
 318 Notification. It is used to identify the source of a value or notification.
 319
 320  class PluginData(object)
 321
 322 This is an internal class that is the base for Values and Notification. It is
 323 pretty useless by itself and was therefore not exported to the collectd module.
 324
 325 Data descriptors defined here:
 326
 327 =over 4
 328
 329 =item host
 330
 331 The hostname of the host this value was read from. For dispatching this can be
 332 set to an empty string which means the local hostname as defined in
 333 collectd.conf.
 334
 335 =item plugin
 336
 337 The name of the plugin that read the data. Setting this member to an empty
 338 string will insert "python" upon dispatching.
 339
 340 =item plugin_instance
 341
 342 Plugin instance string. May be empty.
 343
 344 =item time
 345
 346 This is the Unix timestamp of the time this value was read. For dispatching
 347 values this can be set to zero which means "now". This means the time the value
 348 is actually dispatched, not the time it was set to 0.
 349
 350 =item type
 351
 352 The type of this value. This type has to be defined in your I<types.db>.
 353 Attempting to set it to any other value will raise a I<TypeError> exception.
 354 Assigning a type is mandatory, calling dispatch without doing so will raise a
 355 I<RuntimeError> exception.
 356
 357 =item type_instance
 358
 359 Type instance string. May be empty.
 360
 361 =back
 362
 363 =head2 Values
 364
 365 A Value is an object which features a sequence of values. It is based on the
 366 I<PluginData> type and uses its members to identify the values.
 367
 368  class Values(PluginData)
 369
 370 A Values object used for dispatching values to collectd and receiving values
 371 from write callbacks.
 372
 373 Method resolution order:
 374
 375 =over 4
 376
 377 =item Values
 378
 379 =item PluginData
 380
 381 =item object
 382
 383 =back
 384
 385 Methods defined here:
 386
 387 =over 4
 388
 389 =item B<dispatch>([type][, values][, plugin_instance][, type_instance][, plugin][, host][, time][, interval]) -> None.
 390
 391 Dispatch this instance to the collectd process. The object has members for each
 392 of the possible arguments for this method. For a detailed explanation of these
 393 parameters see the member of the same same.
 394
 395 If you do not submit a parameter the value saved in its member will be
 396 submitted. If you do provide a parameter it will be used instead, without
 397 altering the member.
 398
 399 =item B<write>([destination][, type][, values][, plugin_instance][, type_instance][, plugin][, host][, time][, interval]) -> None.
 400
 401 Write this instance to a single plugin or all plugins if "destination" is
 402 omitted. This will bypass the main collectd process and all filtering and
 403 caching. Other than that it works similar to "dispatch". In most cases
 404 "dispatch" should be used instead of "write".
 405
 406 =back
 407
 408 Data descriptors defined here:
 409
 410 =over 4
 411
 412 =item interval
 413
 414 The interval is the timespan in seconds between two submits for the same data
 415 source. This value has to be a positive integer, so you can't submit more than
 416 one value per second. If this member is set to a non-positive value, the
 417 default value as specified in the config file will be used (default: 10).
 418
 419 If you submit values more often than the specified interval, the average will
 420 be used. If you submit less values, your graphs will have gaps.
 421
 422 =item values
 423
 424 These are the actual values that get dispatched to collectd. It has to be a
 425 sequence (a tuple or list) of numbers. The size of the sequence and the type of
 426 its content depend on the type member your I<types.db> file. For more
 427 information on this read the L<types.db(5)> manual page.
 428
 429 If the sequence does not have the correct size upon dispatch a I<RuntimeError>
 430 exception will be raised. If the content of the sequence is not a number, a
 431 I<TypeError> exception will be raised.
 432
 433 =item meta
 434
 435 These are the meta data for this Value object.
 436 It has to be a dictionary of numbers, strings or bools. All keys must be
 437 strings. I<int> and <long> objects will be dispatched as signed integers unless
 438 they are between 2**63 and 2**64-1, which will result in a unsigned integer.
 439 You can force one of these storage classes by using the classes
 440 B<collectd.Signed> and B<collectd.Unsigned>. A meta object received by a write
 441 callback will always contain B<Signed> or B<Unsigned> objects.
 442
 443 =back
 444
 445 =head2 Notification
 446
 447 A notification is an object defining the severity and message of the status
 448 message as well as an identification of a data instance by means of the members
 449 of I<PluginData> on which it is based.
 450
 451 class Notification(PluginData)
 452 The Notification class is a wrapper around the collectd notification.
 453 It can be used to notify other plugins about bad stuff happening. It works
 454 similar to Values but has a severity and a message instead of interval
 455 and time.
 456 Notifications can be dispatched at any time and can be received with
 457 register_notification.
 458
 459 Method resolution order:
 460
 461 =over 4
 462
 463 =item Notification
 464
 465 =item PluginData
 466
 467 =item object
 468
 469 =back
 470
 471 Methods defined here:
 472
 473 =over 4
 474
 475 =item B<dispatch>([type][, values][, plugin_instance][, type_instance][, plugin][, host][, time][, interval]) -> None.  Dispatch a value list.
 476
 477 Dispatch this instance to the collectd process. The object has members for each
 478 of the possible arguments for this method. For a detailed explanation of these
 479 parameters see the member of the same same.
 480
 481 If you do not submit a parameter the value saved in its member will be
 482 submitted. If you do provide a parameter it will be used instead, without
 483 altering the member.
 484
 485 =back
 486
 487 Data descriptors defined here:
 488
 489 =over 4
 490
 491 =item message
 492
 493 Some kind of description of what's going on and why this Notification was
 494 generated.
 495
 496 =item severity
 497
 498 The severity of this notification. Assign or compare to I<NOTIF_FAILURE>,
 499 I<NOTIF_WARNING> or I<NOTIF_OKAY>.
 500
 501 =back
 502
 503 =head1 FUNCTIONS
 504
 505 The following functions provide the C-interface to Python-modules.
 506
 507 =over 4
 508
 509 =item B<register_*>(I<callback>[, I<data>][, I<name>]) -> identifier
 510
 511 There are eight different register functions to get callback for eight
 512 different events. With one exception all of them are called as shown above.
 513
 514 =over 4
 515
 516 =item *
 517
 518 I<callback> is a callable object that will be called every time the event is
 519 triggered.
 520
 521 =item *
 522
 523 I<data> is an optional object that will be passed back to the callback function
 524 every time it is called. If you omit this parameter no object is passed back to
 525 your callback, not even None.
 526
 527 =item *
 528
 529 I<name> is an optional identifier for this callback. The default name is
 530 B<python>.I<module>. I<module> is taken from the B<__module__> attribute of
 531 your callback function. Every callback needs a unique identifier, so if you
 532 want to register the same callback multiple times in the same module you need to
 533 specify a name here. Otherwise it's safe to ignore this parameter.
 534
 535 =item *
 536
 537 I<identifier> is the full identifier assigned to this callback.
 538
 539 =back
 540
 541 These functions are called in the various stages of the daemon (see the section
 542 L<"WRITING YOUR OWN PLUGINS"> above) and are passed the following arguments:
 543
 544 =over 4
 545
 546 =item register_config
 547
 548 The only argument passed is a I<Config> object. See above for the layout of this
 549 data type.
 550 Note that you cannot receive the whole config files this way, only B<Module>
 551 blocks inside the Python configuration block. Additionally you will only
 552 receive blocks where your callback identifier matches B<python.>I<blockname>.
 553
 554 =item register_init
 555
 556 The callback will be called without arguments.
 557
 558 =item register_read(callback[, interval][, data][, name]) -> identifier
 559
 560 This function takes an additional parameter: I<interval>. It specifies the
 561 time between calls to the callback function.
 562
 563 The callback will be called without arguments.
 564
 565 =item register_shutdown
 566
 567 The callback will be called without arguments.
 568
 569 =item register_write
 570
 571 The callback function will be called with one argument passed, which will be a
 572 I<Values> object. For the layout of I<Values> see above.
 573 If this callback function throws an exception the next call will be delayed by
 574 an increasing interval.
 575
 576 =item register_flush
 577
 578 Like B<register_config> is important for this callback because it determines
 579 what flush requests the plugin will receive.
 580
 581 The arguments passed are I<timeout> and I<identifier>. I<timeout> indicates
 582 that only data older than I<timeout> seconds is to be flushed. I<identifier>
 583 specifies which values are to be flushed.
 584
 585 =item register_log
 586
 587 The arguments are I<severity> and I<message>. The severity is an integer and
 588 small for important messages and high for less important messages. The least
 589 important level is B<LOG_DEBUG>, the most important level is B<LOG_ERR>. In
 590 between there are (from least to most important): B<LOG_INFO>, B<LOG_NOTICE>,
 591 and B<LOG_WARNING>. I<message> is simply a string B<without> a newline at the
 592 end.
 593
 594 If this callback throws an exception it will B<not> be logged. It will just be
 595 printed to B<sys.stderr> which usually means silently ignored.
 596
 597 =item register_notification
 598
 599 The only argument passed is a I<Notification> object. See above for the layout of this
 600 data type.
 601
 602 =back
 603
 604 =item B<unregister_*>(I<identifier>) -> None
 605
 606 Removes a callback or data-set from collectd's internal list of callback
 607 functions. Every I<register_*> function has an I<unregister_*> function.
 608 I<identifier> is either the string that was returned by the register function
 609 or a callback function. The identifier will be constructed in the same way as
 610 for the register functions.
 611
 612 =item B<flush>(I<plugin[, timeout][, identifier]) -> None
 613
 614 Flush one or all plugins. I<timeout> and the specified I<identifiers> are
 615 passed on to the registered flush-callbacks. If omitted, the timeout defaults
 616 to C<-1>. The identifier defaults to None. If the B<plugin> argument has been
 617 specified, only named plugin will be flushed.
 618
 619 =item B<error>, B<warning>, B<notice>, B<info>, B<debug>(I<message>)
 620
 621 Log a message with the specified severity.
 622
 623 =back
 624
 625 =head1 EXAMPLES
 626
 627 Any Python module will start similar to:
 628
 629   import collectd
 630
 631 A very simple read function might look like:
 632
 633   def read(data=None):
 634     vl = collectd.Values(type='gauge')
 635     vl.plugin='python.spam'
 636     vl.dispatch(values=[random.random() * 100])
 637
 638 A very simple write function might look like:
 639
 640   def write(vl, data=None):
 641     for i in vl.values:
 642       print "%s (%s): %f" % (vl.plugin, vl.type, i)
 643
 644 To register those functions with collectd:
 645
 646   collectd.register_read(read);
 647   collectd.register_write(write);
 648
 649 See the section L<"CLASSES"> above for a complete documentation of the data
 650 types used by the read, write and match functions.
 651
 652 =head1 NOTES
 653
 654 =over 4
 655
 656 =item *
 657
 658 Please feel free to send in new plugins to collectd's mailing list at
 659 E<lt>collectdE<nbsp>atE<nbsp>verplant.orgE<gt> for review and, possibly,
 660 inclusion in the main distribution. In the latter case, we will take care of
 661 keeping the plugin up to date and adapting it to new versions of collectd.
 662
 663 Before submitting your plugin, please take a look at
 664 L<http://collectd.org/dev-info.shtml>.
 665
 666 =back
 667
 668 =head1 CAVEATS
 669
 670 =over 4
 671
 672 =item *
 673
 674 collectd is heavily multi-threaded. Each collectd thread accessing the Python
 675 plugin will be mapped to a Python interpreter thread. Any such thread will be
 676 created and destroyed transparently and on-the-fly.
 677
 678 Hence, any plugin has to be thread-safe if it provides several entry points
 679 from collectd (i.E<nbsp>e. if it registers more than one callback or if a
 680 registered callback may be called more than once in parallel).
 681
 682 =item *
 683
 684 The Python thread module is initialized just before calling the init callbacks.
 685 This means you must not use Python's threading module prior to this point. This
 686 includes all config and possibly other callback as well.
 687
 688 =item *
 689
 690 The python plugin exports the internal API of collectd which is considered
 691 unstable and subject to change at any time. We try hard to not break backwards
 692 compatibility in the Python API during the life cycle of one major release.
 693 However, this cannot be guaranteed at all times. Watch out for warnings
 694 dispatched by the python plugin after upgrades.
 695
 696 =back
 697
 698 =head1 KNOWN BUGS
 699
 700 =over 4
 701
 702 =item *
 703
 704 Not all aspects of the collectd API are accessible from Python. This includes
 705 but is not limited to filters and data sets.
 706
 707 =back
 708
 709 =head1 SEE ALSO
 710
 711 L<collectd(1)>,
 712 L<collectd.conf(5)>,
 713 L<collectd-perl(5)>,
 714 L<collectd-exec(5)>,
 715 L<types.db(5)>,
 716 L<python(1)>,
 717
 718 =head1 AUTHOR
 719
 720 The C<python plugin> has been written by
 721 Sven Trenkel E<lt>collectdE<nbsp>atE<nbsp>semidefinite.deE<gt>.
 722
 723 This manpage has been written by Sven Trenkel
 724 E<lt>collectdE<nbsp>atE<nbsp>semidefinite.deE<gt>.
 725 It is based on the L<collectd-perl(5)> manual page by
 726 Florian Forster E<lt>octoE<nbsp>atE<nbsp>verplant.orgE<gt> and
 727 Sebastian Harl E<lt>shE<nbsp>atE<nbsp>tokkee.orgE<gt>.
 728
 729 =cut