Re: [Zope-dev] Is there an alternative to zdaemon?

2006-12-23 Thread Jens Vagelpohl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 23 Dec 2006, at 14:53, Jim Fulton wrote:
> I don't think it ever caused anyone any headache apart from maybe  
working
around different ways in which forking/daemonizing is handled on  
some platforms (OS X comes to mind).


Any software we own is an inherent liability.  Of course, hopefully,
most things we own provide enough benefits to overcome this inherent
liability.

I agree that there may not be alternatives compelling enough to
justify a change.


To be honest, I'm coming across many situations where maintenance and  
upgrade issues make me wish the original developers had reinvented a  
couple wheels instead of relying on third party packages. Even if  
they work fine right now you'll have the risk of incompatibilities or  
lack of reaction when it comes to fixing bugs that make your life  
harder down the line.


zdaemon is a little different of course, it's a "standalone"  
functionality in a way. It's not some Zope product that other  
packages rely on.


jens


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFjTzTRAx5nvEhZLIRAlQGAJ9CJkklU/H9cyn+ayTPWQDjm8zOUQCggj9p
zaBUE/Pze8m+cEr2P6ghUxk=
=PLqx
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Is there an alternative to zdaemon?

2006-12-23 Thread Jim Fulton

Jens Vagelpohl wrote:
...
So with all that said, what's the use case for switching zdaemon out for 
something else?


Not owning it. :)

> What other functionalities are *you* looking for?

Ditto.

> I don't think it ever caused anyone any headache apart from maybe working
around different ways in which forking/daemonizing is handled on some 
platforms (OS X comes to mind).


Any software we own is an inherent liability.  Of course, hopefully,
most things we own provide enough benefits to overcome this inherent
liability.

I agree that there may not be alternatives compelling enough to
justify a change.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Is there an alternative to zdaemon?

2006-12-23 Thread Jens Vagelpohl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 23 Dec 2006, at 14:23, Jim Fulton wrote:

zdaemon is an interesting case because it is s non-zope and
(mostly) non-python specific.  I must say that it amazes me that there
isn't an established alternative out there.


When people start talking about such functionalities I only ever see  
Daemontools mentioned. I never used it, but from your description it  
seems to have some shortcomings.



One point in zdaemon's favor that I forgot about in my original  
analysis
is that it has a (also undocumented) subclassing API that allows  
applications
to add new commands.  We certainly leverage this to provide the  
debug and

run commands.

supervisor2 looks very cool.  But it is also "ours" in some sense.   
It also
is much bigger than zdaemon.  It looks like like something that  
people will
often choose over zdaemon.  zdaemon is still attractive to me over  
supervisor2
because it is smaller, less ambitious and I already understand  
it. :) And, of course,

there are the good backward compatibility arguments that you make.


So with all that said, what's the use case for switching zdaemon out  
for something else? What other functionalities are *you* looking for?  
I don't think it ever caused anyone any headache apart from maybe  
working around different ways in which forking/daemonizing is handled  
on some platforms (OS X comes to mind).


jens


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFFjTGMRAx5nvEhZLIRAt3TAKCCeKr94fU3Vp9wkyhYDCOLmZpGpgCdFjau
HeEVqYANXGEMMfmmdbhmvRw=
=jy2/
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Is there an alternative to zdaemon?

2006-12-23 Thread Jim Fulton

Andreas Jung wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



- --On 22. Dezember 2006 15:55:48 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:

It has 2 major disadvantages:

- It is ours. :)  We are bearing the burden of maintaining it.
   This is offset by the fact that it hasn't required much maintenance.


..which is actually a sign of "it-just-works".


- It is largely undocumented. This makes it much harder to use than it
   needs to be.  It also makes it under appreciated.  I made a start at
   fixing this yesterday:

 http://svn.zope.org/zdaemon/trunk/src/zdaemon/README.txt?view=auto

  It isn't very hard to use, so documenting it isn't really all that hard.


...which is almost True for a lot of parts of the Zope 2 core  :-)



I wonder if we should be using some other daemon manager.  Arguably,
there's
no reason for the Zope project to maintain one if something is available
that does what we need.


I think (meanwhile) that this is not enough to justify the replacement of a 
component. Replacing a Zope 2 component always caused some pain. So as a 
rule for replacing something in the Zope 2 core we consider those rules:


 - the replacement solves  existing functional problems

 - it adds major functional benefits

 - no issues with backward compatibility, well tested etc.

For the Zope 2 core we must be very careful about changing stuff. Stability
and backward compatibility are much, much more important for the end-user 
than satisfying our replace-all-with-something-better drive :-)


Don't get me wrong but we've done some minor mistakes with replacing stuff 
in the past  and because of that I became a bit conservative about changing 
things. Of course I am only speaking for the Zope 2 core.


I feel the same need for conservatism.  These are all good arguments.

A strong counter force is that we seem to have more on our plate than we
can handle.  We either need to get more people helping, or we need to do
less.  Something to keep in mind is that many people who help now actually
want and deserver to be able to do new things too. :)

zdaemon is an interesting case because it is s non-zope and
(mostly) non-python specific.  I must say that it amazes me that there
isn't an established alternative out there.

One point in zdaemon's favor that I forgot about in my original analysis
is that it has a (also undocumented) subclassing API that allows applications
to add new commands.  We certainly leverage this to provide the debug and
run commands.

supervisor2 looks very cool.  But it is also "ours" in some sense.  It also
is much bigger than zdaemon.  It looks like like something that people will
often choose over zdaemon.  zdaemon is still attractive to me over supervisor2
because it is smaller, less ambitious and I already understand it. :) And, of 
course,
there are the good backward compatibility arguments that you make.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Is there an alternative to zdaemon?

2006-12-22 Thread Andreas Jung
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



- --On 22. Dezember 2006 15:55:48 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:
>
> It has 2 major disadvantages:
>
> - It is ours. :)  We are bearing the burden of maintaining it.
>This is offset by the fact that it hasn't required much maintenance.

..which is actually a sign of "it-just-works".

>
> - It is largely undocumented. This makes it much harder to use than it
>needs to be.  It also makes it under appreciated.  I made a start at
>fixing this yesterday:
>
>  http://svn.zope.org/zdaemon/trunk/src/zdaemon/README.txt?view=auto
>
>   It isn't very hard to use, so documenting it isn't really all that hard.

...which is almost True for a lot of parts of the Zope 2 core  :-)


>
> I wonder if we should be using some other daemon manager.  Arguably,
> there's
> no reason for the Zope project to maintain one if something is available
> that does what we need.

I think (meanwhile) that this is not enough to justify the replacement of a 
component. Replacing a Zope 2 component always caused some pain. So as a 
rule for replacing something in the Zope 2 core we consider those rules:

 - the replacement solves  existing functional problems

 - it adds major functional benefits

 - no issues with backward compatibility, well tested etc.

For the Zope 2 core we must be very careful about changing stuff. Stability
and backward compatibility are much, much more important for the end-user 
than satisfying our replace-all-with-something-better drive :-)

Don't get me wrong but we've done some minor mistakes with replacing stuff 
in the past  and because of that I became a bit conservative about changing 
things. Of course I am only speaking for the Zope 2 core.

Andreas


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFFjLuICJIWIbr9KYwRAgsRAJ9p3Td7KOmKzHzLn89nnQpSdYMtnwCcDyDR
iKgZV5H76vnCpjqO3Mccrv4=
=DYYW
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Is there an alternative to zdaemon?

2006-12-22 Thread Jim Fulton

Yesterday I started working on some updates to zdaemon.  zdaemon is pretty
cool.  It is a Unix-only tool that:

- Turns an arbitrary program into a fairly well-behaved daemon

- Provides management of an applications output as a log file.

- Provides start, stop and restart commands for starting or stopping
  applications.

- Provides a status command for finding out if an app is running.

- Provides a kill command for sending an app a signal (e.g. for
  log rotation).

- Automatically restarts applications that exit abnormally, with a
  fairly reasonable approach for limiting restart attempts in case
  something is failing on startup.

- Provides a number of useful configuration settings that can
  be managed using a clean (ZConfig-based) log file.

It is written in Python, but it can control any program.  We're using
it to control spread, which is a C program.  spread comes with it's
own Red Hat startup script, but spread fails to detach from the
controlling terminal.  zdaemon makes it behave properly and provides
a startup script that will work on any Unix-like system.

It has 2 major disadvantages:

- It is ours. :)  We are bearing the burden of maintaining it.
  This is offset by the fact that it hasn't required much maintenance.

- It is largely undocumented. This makes it much harder to use than it
  needs to be.  It also makes it under appreciated.  I made a start at
  fixing this yesterday:

http://svn.zope.org/zdaemon/trunk/src/zdaemon/README.txt?view=auto

 It isn't very hard to use, so documenting it isn't really all that hard.

I wonder if we should be using some other daemon manager.  Arguably, there's
no reason for the Zope project to maintain one if something is available
that does what we need.  Does anyone know of something that does what zdaemon
does?  daemontools seems somewhat close:

  http://cr.yp.to/daemontools.html

Going from the documentation, it doesn't seem to be as clever about
application restart.  The documentation says nothing about distinguishing
between normal and abnormal restarts or avoiding useless restarts when there
are start-up errors.

If we do continue to maintain zdaemon, we really should publicize it more
widely, both to get credit and to get more people interested in maintaining
it.

Because I want the enhancements I'm making for another project I'm working
on, I'm going to proceed with them for now.

Thoughts?

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )