[Zope-Checkins] CVS: Zope/doc - SIGNALS.txt:1.3.10.1 CHANGES.txt:1.528.2.8

Chris McDonough chrism@zope.com
Sat, 26 Oct 2002 15:52:06 -0400


Update of /cvs-repository/Zope/doc
In directory cvs.zope.org:/tmp/cvs-serv31373/doc

Modified Files:
      Tag: chrism-install-branch
	CHANGES.txt 
Added Files:
      Tag: chrism-install-branch
	SIGNALS.txt 
Log Message:
Merge with HEAD.  Again, sorry for the spew (what's left of it... someone seems to have filtered some of this branch's checkins out).


=== Added File Zope/doc/SIGNALS.txt ===
Signals (POSIX only)

  Signals are a POSIX inter-process communications mechanism.
  If you are using Windows then this documentation does not apply.

  Zope responds to signals which are sent to the process id
  specified in the file 'ZOPE_HOME/var/Z2.pid'::

    SIGHUP  - close open database connections, then restart the server
              process. The common idiom for restarting a Zope server is:

              kill -HUP `cat ZOPE_HOME/var/z2.pid`

    SIGTERM - close open database connections then shut down. The common
              idiom for shutting down Zope is:

              kill -TERM `cat ZOPE_HOME/var/Z2.pid`

    SIGINT  - same as SIGTERM

    SIGUSR2 - close and re-open all Zope log files (z2.log, event log,
              detailed log.) The common idiom after rotating Zope log files
              is:

              kill -USR2 `cat ZOPE_HOME var/z2.pid`

  The process id written to the 'z2.pid' file depends on whether Zope
  is run under the 'zdaemon' management process. If Zope is run under
  a management process (as it is by default) then the pid of the
  management process is recorded here.  Relevant signals sent to the
  management process are forwarded on to the server process.
  Specifically, it forwards all those signals listed above, plus
  SIGQUIT and SIGUSR1.  If Zope is not using a management process (-Z0
  on the z2.py command line), the server process records its own pid
  into 'z2.pid', but all signals work the same way.


=== Zope/doc/CHANGES.txt 1.528.2.7 => 1.528.2.8 ===
--- Zope/doc/CHANGES.txt:1.528.2.7	Tue Oct  8 17:45:37 2002
+++ Zope/doc/CHANGES.txt	Sat Oct 26 15:51:35 2002
@@ -8,6 +8,10 @@
     
     Features Added
 
+      - ZTUtils.Iterator now handles any object that has a Python
+        iterator, resolving Collector #385 and #577.  The
+        implementation is somwhat simpler, as well.
+
       - ZTUtils.Tree.TreeMaker now has additional methods for setting
         various flags and attributes that influence how the tree is built,
         making these aspects accessible to PythonScripts.
@@ -28,6 +32,17 @@
 
     Bugs Fixed
 
+      - Removed the signal handler hung off USR1 for packing the database.
+        This feature proved dangerous as the pack operation would happen in
+        the main thread, causing all asyncore operations to stop until it
+        was finished.
+
+      - Collector #372: tal:attributes failed when combined with tal:replace.
+      - Don't try to close network connections in the signal handler
+        for shutdown.  This hosed ZEO clients.
+
+      - Collector #292: PythonScript.write() didn't properly refresh bindings.
+
       - Dumb bug in zdaemon fixed in which it would try to kill
         process numbers 1, 2, 3, 10, 12, and 15 when it caught a
         signal related to any of these signal numbers.   Instead, it
@@ -35,7 +50,7 @@
         signal.
 
       - Write pidfiles out with trailing newlines.
-
+      
   Zope 2.6.0 beta 1
 
     Bugs Fixed
@@ -283,8 +298,8 @@
         unquoted id
 
       - Collector #61 -- now manage_PasteObjects return a list of dictionaries
-	containing {'id':original_id,'new_id':newly_pasted_obj_id} when called
-	with REQUEST=None
+    containing {'id':original_id,'new_id':newly_pasted_obj_id} when called
+    with REQUEST=None
 
       - Changed FORCE_PRODUCT_LOAD so that if it is set, it determines
         whether products are installed regardless of whether ZEO_CACHE is
@@ -452,10 +467,10 @@
 
       - New implementation of ZODB object cache.  The new
         implemenation is more likely to keep the size of the object
-	cache close to the target size.  This change means that memory
-	consumption may be reduced.  Some users will need to increase
-	the default cache size, because a too small setting is more
-	likely to hurt performance than it did in the past.
+    cache close to the target size.  This change means that memory
+    consumption may be reduced.  Some users will need to increase
+    the default cache size, because a too small setting is more
+    likely to hurt performance than it did in the past.
 
         Third-party C extensions that use the persistence API must be
         recompiled, and may need to be updated to work correctly with