pyldb: avoid segfault when adding an element with no name
[vlendec/samba-autobuild/.git] / ctdb / doc / ctdb-tunables.7.xml
1 <?xml version="1.0" encoding="iso-8859-1"?>
2 <!DOCTYPE refentry
3         PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
4         "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
5
6 <refentry id="ctdb-tunables.7">
7
8   <refmeta>
9     <refentrytitle>ctdb-tunables</refentrytitle>
10     <manvolnum>7</manvolnum>
11     <refmiscinfo class="source">ctdb</refmiscinfo>
12     <refmiscinfo class="manual">CTDB - clustered TDB database</refmiscinfo>
13   </refmeta>
14
15   <refnamediv>
16     <refname>ctdb-tunables</refname>
17     <refpurpose>CTDB tunable configuration variables</refpurpose>
18   </refnamediv>
19
20   <refsect1>
21     <title>DESCRIPTION</title>
22
23     <para>
24       CTDB's behaviour can be configured by setting run-time tunable
25       variables.  This lists and describes all tunables.  See the
26       <citerefentry><refentrytitle>ctdb</refentrytitle>
27       <manvolnum>1</manvolnum></citerefentry>
28       <command>listvars</command>, <command>setvar</command> and
29       <command>getvar</command> commands for more details.
30     </para>
31
32     <para>
33       Unless otherwise stated, tunables should be set to the same
34       value on all nodes.  Setting tunables to different values across
35       nodes may produce unexpected results.  Future releases may set
36       (some or most) tunables globally across the cluster but doing so
37       is currently a manual process.
38     </para>
39
40     <para>
41       Tunables can be set at startup from the
42       <filename>/usr/local/etc/ctdb/ctdb.tunables</filename>
43       configuration file.
44
45       <literallayout>
46 <replaceable>TUNABLE</replaceable>=<replaceable>VALUE</replaceable>
47       </literallayout>
48     </para>
49
50     <para>
51       For example:
52
53       <screen format="linespecific">
54 MonitorInterval=20
55       </screen>
56     </para>
57
58     <para>
59       The available tunable variables are listed alphabetically below.
60     </para>
61
62     <refsect2>
63       <title>AllowClientDBAttach</title>
64       <para>Default: 1</para>
65       <para>
66         When set to 0, clients are not allowed to attach to any databases.
67         This can be used to temporarily block any new processes from
68         attaching to and accessing the databases.  This is mainly used
69         for detaching a volatile database using 'ctdb detach'.
70       </para>
71     </refsect2>
72
73     <refsect2>
74       <title>AllowMixedVersions</title>
75       <para>Default: 0</para>
76       <para>
77         CTDB will not allow incompatible versions to co-exist in
78         a cluster.  If a version mismatch is found, then losing CTDB
79         will shutdown.  To disable the incompatible version check,
80         set this tunable to 1.
81       </para>
82       <para>
83         For version checking, CTDB uses major and minor version.
84         For example, CTDB 4.6.1 and CTDB CTDB 4.6.2 are matching versions;
85         CTDB 4.5.x and CTDB 4.6.y do not match.
86       </para>
87       <para>
88         CTDB with version check support will lose to CTDB without
89         version check support.  Between two different CTDB versions with
90         version check support, one running for less time will lose.
91         If the running time for both CTDB versions with version check
92         support is equal (to seconds), then the older version will lose.
93         The losing CTDB daemon will shutdown.
94       </para>
95     </refsect2>
96
97     <refsect2>
98       <title>AllowUnhealthyDBRead</title>
99       <para>Default: 0</para>
100       <para>
101         When set to 1, ctdb allows database traverses to read unhealthy
102         databases.  By default, ctdb does not allow reading records from
103         unhealthy databases.
104       </para>
105     </refsect2>
106
107     <refsect2>
108       <title>ControlTimeout</title>
109       <para>Default: 60</para>
110       <para>
111         This is the default setting for timeout for when sending a
112         control message to either the local or a remote ctdb daemon.
113       </para>
114     </refsect2>
115
116     <refsect2>
117       <title>DatabaseHashSize</title>
118       <para>Default: 100001</para>
119       <para>
120         Number of the hash chains for the local store of the tdbs that
121         ctdb manages.
122       </para>
123     </refsect2>
124
125     <refsect2>
126       <title>DatabaseMaxDead</title>
127       <para>Default: 5</para>
128       <para>
129         Maximum number of dead records per hash chain for the tdb databses
130         managed by ctdb.
131       </para>
132     </refsect2>
133
134     <refsect2>
135       <title>DBRecordCountWarn</title>
136       <para>Default: 100000</para>
137       <para>
138         When set to non-zero, ctdb will log a warning during recovery if
139         a database has more than this many records. This will produce a
140         warning if a database grows uncontrollably with orphaned records.
141       </para>
142     </refsect2>
143
144     <refsect2>
145       <title>DBRecordSizeWarn</title>
146       <para>Default: 10000000</para>
147       <para>
148         When set to non-zero, ctdb will log a warning during recovery
149         if a single record is bigger than this size. This will produce
150         a warning if a database record grows uncontrollably.
151       </para>
152     </refsect2>
153
154     <refsect2>
155       <title>DBSizeWarn</title>
156       <para>Default: 1000000000</para>
157       <para>
158         When set to non-zero, ctdb will log a warning during recovery if
159         a database size is bigger than this. This will produce a warning
160         if a database grows uncontrollably.
161       </para>
162     </refsect2>
163
164     <refsect2>
165       <title>DeferredAttachTO</title>
166       <para>Default: 120</para>
167       <para>
168         When databases are frozen we do not allow clients to attach to
169         the databases. Instead of returning an error immediately to the
170         client, the attach request from the client is deferred until
171         the database becomes available again at which stage we respond
172         to the client.
173       </para>
174       <para>
175         This timeout controls how long we will defer the request from the
176         client before timing it out and returning an error to the client.
177       </para>
178     </refsect2>
179
180     <refsect2>
181       <title>ElectionTimeout</title>
182       <para>Default: 3</para>
183       <para>
184         The number of seconds to wait for the election of recovery
185         master to complete. If the election is not completed during this
186         interval, then that round of election fails and ctdb starts a
187         new election.
188       </para>
189     </refsect2>
190
191     <refsect2>
192       <title>EnableBans</title>
193       <para>Default: 1</para>
194       <para>
195         This parameter allows ctdb to ban a node if the node is misbehaving.
196       </para>
197       <para>
198         When set to 0, this disables banning completely in the cluster
199         and thus nodes can not get banned, even it they break. Don't
200         set to 0 unless you know what you are doing.
201       </para>
202     </refsect2>
203
204     <refsect2>
205       <title>EventScriptTimeout</title>
206       <para>Default: 30</para>
207       <para>
208         Maximum time in seconds to allow an event to run before timing
209         out.  This is the total time for all enabled scripts that are
210         run for an event, not just a single event script.
211       </para>
212       <para>
213         Note that timeouts are ignored for some events ("takeip",
214         "releaseip", "startrecovery", "recovered") and converted to
215         success.  The logic here is that the callers of these events
216         implement their own additional timeout.
217       </para>
218     </refsect2>
219
220     <refsect2>
221       <title>FetchCollapse</title>
222       <para>Default: 1</para>
223       <para>
224        This parameter is used to avoid multiple migration requests for
225        the same record from a single node. All the record requests for
226        the same record are queued up and processed when the record is
227        migrated to the current node.
228       </para>
229       <para>
230         When many clients across many nodes try to access the same record
231         at the same time this can lead to a fetch storm where the record
232         becomes very active and bounces between nodes very fast. This
233         leads to high CPU utilization of the ctdbd daemon, trying to
234         bounce that record around very fast, and poor performance.
235         This can improve performance and reduce CPU utilization for
236         certain workloads.
237       </para>
238     </refsect2>
239
240     <refsect2>
241       <title>HopcountMakeSticky</title>
242       <para>Default: 50</para>
243       <para>
244         For database(s) marked STICKY (using 'ctdb setdbsticky'),
245         any record that is migrating so fast that hopcount
246         exceeds this limit is marked as STICKY record for
247         <varname>StickyDuration</varname> seconds. This means that
248         after each migration the sticky record will be kept on the node
249         <varname>StickyPindown</varname>milliseconds and prevented from
250         being migrated off the node.
251        </para>
252        <para>
253         This will improve performance for certain workloads, such as
254         locking.tdb if many clients are opening/closing the same file
255         concurrently.
256       </para>
257     </refsect2>
258
259     <refsect2>
260       <title>IPAllocAlgorithm</title>
261       <para>Default: 2</para>
262       <para>
263         Selects the algorithm that CTDB should use when doing public
264         IP address allocation.  Meaningful values are:
265       </para>
266       <variablelist>
267         <varlistentry>
268           <term>0</term>
269           <listitem>
270             <para>
271               Deterministic IP address allocation.
272             </para>
273             <para>
274               This is a simple and fast option.  However, it can cause
275               unnecessary address movement during fail-over because
276               each address has a "home" node.  Works badly when some
277               nodes do not have any addresses defined.  Should be used
278               with care when addresses are defined across multiple
279               networks.
280             </para>
281           </listitem>
282         </varlistentry>
283         <varlistentry>
284           <term>1</term>
285           <listitem>
286             <para>
287               Non-deterministic IP address allocation.
288             </para>
289             <para>
290               This is a relatively fast option that attempts to do a
291               minimise unnecessary address movements.  Addresses do
292               not have a "home" node.  Rebalancing is limited but it
293               usually adequate.  Works badly when addresses are
294               defined across multiple networks.
295             </para>
296           </listitem>
297         </varlistentry>
298         <varlistentry>
299           <term>2</term>
300           <listitem>
301             <para>
302               LCP2 IP address allocation.
303             </para>
304             <para>
305               Uses a heuristic to assign addresses defined across
306               multiple networks, usually balancing addresses on each
307               network evenly across nodes.  Addresses do not have a
308               "home" node.  Minimises unnecessary address movements.
309               The algorithm is complex, so is slower than other
310               choices for a large number of addresses.  However, it
311               can calculate an optimal assignment of 900 addresses in
312               under 10 seconds on modern hardware.
313             </para>
314           </listitem>
315         </varlistentry>
316       </variablelist>
317       <para>
318         If the specified value is not one of these then the default
319         will be used.
320       </para>
321     </refsect2>
322
323     <refsect2>
324       <title>KeepaliveInterval</title>
325       <para>Default: 5</para>
326       <para>
327         How often in seconds should the nodes send keep-alive packets to
328         each other.
329       </para>
330     </refsect2>
331
332     <refsect2>
333       <title>KeepaliveLimit</title>
334       <para>Default: 5</para>
335       <para>
336         After how many keepalive intervals without any traffic should
337         a node wait until marking the peer as DISCONNECTED.
338        </para>
339        <para>
340         If a node has hung, it can take
341         <varname>KeepaliveInterval</varname> *
342         (<varname>KeepaliveLimit</varname> + 1) seconds before
343         ctdb determines that the node is DISCONNECTED and performs
344         a recovery. This limit should not be set too high to enable
345         early detection and avoid any application timeouts (e.g. SMB1)
346         to kick in before the fail over is completed.
347       </para>
348     </refsect2>
349
350     <refsect2>
351       <title>LockProcessesPerDB</title>
352       <para>Default: 200</para>
353       <para>
354         This is the maximum number of lock helper processes ctdb will
355         create for obtaining record locks.  When ctdb cannot get a record
356         lock without blocking, it creates a helper process that waits
357         for the lock to be obtained.
358       </para>
359     </refsect2>
360
361     <refsect2>
362       <title>LogLatencyMs</title>
363       <para>Default: 0</para>
364       <para>
365         When set to non-zero, ctdb will log if certains operations
366         take longer than this value, in milliseconds, to complete.
367         These operations include "process a record request from client",
368         "take a record or database lock", "update a persistent database
369         record" and "vaccum a database".
370       </para>
371     </refsect2>
372
373     <refsect2>
374       <title>MaxQueueDropMsg</title>
375       <para>Default: 1000000</para>
376       <para>
377         This is the maximum number of messages to be queued up for
378         a client before ctdb will treat the client as hung and will
379         terminate the client connection.
380       </para>
381     </refsect2>
382
383     <refsect2>
384       <title>MonitorInterval</title>
385       <para>Default: 15</para>
386       <para>
387         How often should ctdb run the 'monitor' event in seconds to check
388         for a node's health.
389       </para>
390     </refsect2>
391
392     <refsect2>
393       <title>MonitorTimeoutCount</title>
394       <para>Default: 20</para>
395       <para>
396         How many 'monitor' events in a row need to timeout before a node
397         is flagged as UNHEALTHY.  This setting is useful if scripts can
398         not be written so that they do not hang for benign reasons.
399       </para>
400     </refsect2>
401
402     <refsect2>
403       <title>NoIPFailback</title>
404       <para>Default: 0</para>
405       <para>
406         When set to 1, ctdb will not perform failback of IP addresses
407         when a node becomes healthy. When a node becomes UNHEALTHY,
408         ctdb WILL perform failover of public IP addresses, but when the
409         node becomes HEALTHY again, ctdb will not fail the addresses back.
410       </para>
411       <para>
412         Use with caution! Normally when a node becomes available to the
413         cluster ctdb will try to reassign public IP addresses onto the
414         new node as a way to distribute the workload evenly across the
415         clusternode. Ctdb tries to make sure that all running nodes have
416         approximately the same number of public addresses it hosts.
417       </para>
418       <para>
419         When you enable this tunable, ctdb will no longer attempt to
420         rebalance the cluster by failing IP addresses back to the new
421         nodes. An unbalanced cluster will therefore remain unbalanced
422         until there is manual intervention from the administrator. When
423         this parameter is set, you can manually fail public IP addresses
424         over to the new node(s) using the 'ctdb moveip' command.
425       </para>
426     </refsect2>
427
428     <refsect2>
429       <title>NoIPTakeover</title>
430       <para>Default: 0</para>
431       <para>
432         When set to 1, ctdb will not allow IP addresses to be failed
433         over to other nodes.  Any IP addresses already hosted on
434         healthy nodes will remain.  Any IP addresses hosted on
435         unhealthy nodes will be released by unhealthy nodes and will
436         become un-hosted.
437       </para>
438     </refsect2>
439
440     <refsect2>
441       <title>PullDBPreallocation</title>
442       <para>Default: 10*1024*1024</para>
443       <para>
444         This is the size of a record buffer to pre-allocate for sending
445         reply to PULLDB control. Usually record buffer starts with size
446         of the first record and gets reallocated every time a new record
447         is added to the record buffer. For a large number of records,
448         this can be very inefficient to grow the record buffer one record
449         at a time.
450       </para>
451     </refsect2>
452
453     <refsect2>
454       <title>QueueBufferSize</title>
455       <para>Default: 1024</para>
456       <para>
457         This is the maximum amount of data (in bytes) ctdb will read
458         from a socket at a time.
459       </para>
460       <para>
461         For a busy setup, if ctdb is not able to process the TCP sockets
462         fast enough (large amount of data in Recv-Q for tcp sockets),
463         then this tunable value should be increased.  However, large
464         values can keep ctdb busy processing packets and prevent ctdb
465         from handling other events.
466       </para>
467     </refsect2>
468
469     <refsect2>
470       <title>RecBufferSizeLimit</title>
471       <para>Default: 1000000</para>
472       <para>
473         This is the limit on the size of the record buffer to be sent
474         in various controls.  This limit is used by new controls used
475         for recovery and controls used in vacuuming.
476       </para>
477     </refsect2>
478
479     <refsect2>
480       <title>RecdFailCount</title>
481       <para>Default: 10</para>
482       <para>
483         If the recovery daemon has failed to ping the main dameon for
484         this many consecutive intervals, the main daemon will consider
485         the recovery daemon as hung and will try to restart it to recover.
486       </para>
487     </refsect2>
488
489     <refsect2>
490       <title>RecdPingTimeout</title>
491       <para>Default: 60</para>
492       <para>
493         If the main dameon has not heard a "ping" from the recovery dameon
494         for this many seconds, the main dameon will log a message that
495         the recovery daemon is potentially hung.  This also increments a
496         counter which is checked against <varname>RecdFailCount</varname>
497         for detection of hung recovery daemon.
498       </para>
499     </refsect2>
500
501     <refsect2>
502       <title>RecLockLatencyMs</title>
503       <para>Default: 1000</para>
504       <para>
505         When using a reclock file for split brain prevention, if set
506         to non-zero this tunable will make the recovery dameon log a
507         message if the fcntl() call to lock/testlock the recovery file
508         takes longer than this number of milliseconds.
509       </para>
510     </refsect2>
511
512     <refsect2>
513       <title>RecoverInterval</title>
514       <para>Default: 1</para>
515       <para>
516         How frequently in seconds should the recovery daemon perform the
517         consistency checks to determine if it should perform a recovery.
518       </para>
519     </refsect2>
520
521     <refsect2>
522       <title>RecoverTimeout</title>
523       <para>Default: 120</para>
524       <para>
525         This is the default setting for timeouts for controls when sent
526         from the recovery daemon. We allow longer control timeouts from
527         the recovery daemon than from normal use since the recovery
528         dameon often use controls that can take a lot longer than normal
529         controls.
530       </para>
531     </refsect2>
532
533     <refsect2>
534       <title>RecoveryBanPeriod</title>
535       <para>Default: 300</para>
536       <para>
537        The duration in seconds for which a node is banned if the node
538        fails during recovery.  After this time has elapsed the node will
539        automatically get unbanned and will attempt to rejoin the cluster.
540       </para>
541       <para>
542        A node usually gets banned due to real problems with the node.
543        Don't set this value too small.  Otherwise, a problematic node
544        will try to re-join cluster too soon causing unnecessary recoveries.
545       </para>
546     </refsect2>
547
548     <refsect2>
549       <title>RecoveryDropAllIPs</title>
550       <para>Default: 120</para>
551       <para>
552         If a node is stuck in recovery, or stopped, or banned, for this
553         many seconds, then ctdb will release all public addresses on
554         that node.
555       </para>
556     </refsect2>
557
558     <refsect2>
559       <title>RecoveryGracePeriod</title>
560       <para>Default: 120</para>
561       <para>
562        During recoveries, if a node has not caused recovery failures
563        during the last grace period in seconds, any records of
564        transgressions that the node has caused recovery failures will be
565        forgiven. This resets the ban-counter back to zero for that node.
566       </para>
567     </refsect2>
568
569     <refsect2>
570       <title>RepackLimit</title>
571       <para>Default: 10000</para>
572       <para>
573         During vacuuming, if the number of freelist records are more than
574         <varname>RepackLimit</varname>, then the database is repacked
575         to get rid of the freelist records to avoid fragmentation.
576       </para>
577       <para>
578         Databases are repacked only if both <varname>RepackLimit</varname>
579         and <varname>VacuumLimit</varname> are exceeded.
580       </para>
581     </refsect2>
582
583     <refsect2>
584       <title>RerecoveryTimeout</title>
585       <para>Default: 10</para>
586       <para>
587         Once a recovery has completed, no additional recoveries are
588         permitted until this timeout in seconds has expired.
589       </para>
590     </refsect2>
591
592     <refsect2>
593       <title>SeqnumInterval</title>
594       <para>Default: 1000</para>
595       <para>
596         Some databases have seqnum tracking enabled, so that samba will
597         be able to detect asynchronously when there has been updates
598         to the database.  Every time a database is updated its sequence
599         number is increased.
600       </para>
601       <para>
602         This tunable is used to specify in milliseconds how frequently
603         ctdb will send out updates to remote nodes to inform them that
604         the sequence number is increased.
605       </para>
606     </refsect2>
607
608     <refsect2>
609       <title>StatHistoryInterval</title>
610       <para>Default: 1</para>
611       <para>
612         Granularity of the statistics collected in the statistics
613         history. This is reported by 'ctdb stats' command.
614       </para>
615     </refsect2>
616
617     <refsect2>
618       <title>StickyDuration</title>
619       <para>Default: 600</para>
620       <para>
621         Once a record has been marked STICKY, this is the duration in
622         seconds, the record will be flagged as a STICKY record.
623       </para>
624     </refsect2>
625
626     <refsect2>
627       <title>StickyPindown</title>
628       <para>Default: 200</para>
629       <para>
630         Once a STICKY record has been migrated onto a node, it will be
631         pinned down on that node for this number of milliseconds. Any
632         request from other nodes to migrate the record off the node will
633         be deferred.
634       </para>
635     </refsect2>
636
637     <refsect2>
638       <title>TakeoverTimeout</title>
639       <para>Default: 9</para>
640       <para>
641         This is the duration in seconds in which ctdb tries to complete IP
642         failover.
643       </para>
644     </refsect2>
645
646     <refsect2>
647       <title>TickleUpdateInterval</title>
648       <para>Default: 20</para>
649       <para>
650         Every <varname>TickleUpdateInterval</varname> seconds, ctdb
651         synchronizes the client connection information across nodes.
652       </para>
653     </refsect2>
654
655     <refsect2>
656       <title>TraverseTimeout</title>
657       <para>Default: 20</para>
658       <para>
659         This is the duration in seconds for which a database traverse
660         is allowed to run.  If the traverse does not complete during
661         this interval, ctdb will abort the traverse.
662       </para>
663     </refsect2>
664
665     <refsect2>
666       <title>VacuumFastPathCount</title>
667       <para>Default: 60</para>
668       <para>
669        During a vacuuming run, ctdb usually processes only the records
670        marked for deletion also called the fast path vacuuming. After
671        finishing <varname>VacuumFastPathCount</varname> number of fast
672        path vacuuming runs, ctdb will trigger a scan of complete database
673        for any empty records that need to be deleted.
674       </para>
675     </refsect2>
676
677     <refsect2>
678       <title>VacuumInterval</title>
679       <para>Default: 10</para>
680       <para>
681         Periodic interval in seconds when vacuuming is triggered for
682         volatile databases.
683       </para>
684     </refsect2>
685
686     <refsect2>
687       <title>VacuumLimit</title>
688       <para>Default: 5000</para>
689       <para>
690         During vacuuming, if the number of deleted records are more than
691         <varname>VacuumLimit</varname>, then databases are repacked to
692         avoid fragmentation.
693       </para>
694       <para>
695         Databases are repacked only if both <varname>RepackLimit</varname>
696         and <varname>VacuumLimit</varname> are exceeded.
697       </para>
698     </refsect2>
699
700     <refsect2>
701       <title>VacuumMaxRunTime</title>
702       <para>Default: 120</para>
703       <para>
704         The maximum time in seconds for which the vacuuming process is
705         allowed to run.  If vacuuming process takes longer than this
706         value, then the vacuuming process is terminated.
707       </para>
708     </refsect2>
709
710     <refsect2>
711       <title>VerboseMemoryNames</title>
712       <para>Default: 0</para>
713       <para>
714         When set to non-zero, ctdb assigns verbose names for some of
715         the talloc allocated memory objects.  These names are visible
716         in the talloc memory report generated by 'ctdb dumpmemory'.
717       </para>
718     </refsect2>
719
720   </refsect1>
721
722   <refsect1>
723     <title>FILES></title>
724
725     <simplelist>
726       <member><filename>/usr/local/etc/ctdb/ctdb.tunables</filename></member>
727     </simplelist>
728   </refsect1>
729
730   <refsect1>
731     <title>SEE ALSO</title>
732     <para>
733       <citerefentry><refentrytitle>ctdb</refentrytitle>
734       <manvolnum>1</manvolnum></citerefentry>,
735
736       <citerefentry><refentrytitle>ctdbd</refentrytitle>
737       <manvolnum>1</manvolnum></citerefentry>,
738
739       <citerefentry><refentrytitle>ctdb.conf</refentrytitle>
740       <manvolnum>5</manvolnum></citerefentry>,
741
742       <citerefentry><refentrytitle>ctdb</refentrytitle>
743       <manvolnum>7</manvolnum></citerefentry>,
744
745       <ulink url="http://ctdb.samba.org/"/>
746     </para>
747   </refsect1>
748
749   <refentryinfo>
750     <author>
751       <contrib>
752         This documentation was written by
753         Ronnie Sahlberg,
754         Amitay Isaacs,
755         Martin Schwenke
756       </contrib>
757     </author>
758
759     <copyright>
760       <year>2007</year>
761       <holder>Andrew Tridgell</holder>
762       <holder>Ronnie Sahlberg</holder>
763     </copyright>
764     <legalnotice>
765       <para>
766         This program is free software; you can redistribute it and/or
767         modify it under the terms of the GNU General Public License as
768         published by the Free Software Foundation; either version 3 of
769         the License, or (at your option) any later version.
770       </para>
771       <para>
772         This program is distributed in the hope that it will be
773         useful, but WITHOUT ANY WARRANTY; without even the implied
774         warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
775         PURPOSE.  See the GNU General Public License for more details.
776       </para>
777       <para>
778         You should have received a copy of the GNU General Public
779         License along with this program; if not, see
780         <ulink url="http://www.gnu.org/licenses"/>.
781       </para>
782     </legalnotice>
783   </refentryinfo>
784
785 </refentry>