[Twisted-Python] new function for t.i.main
daemonize() is cool, useful and should really be refactored out of twistd I really see no harm in providing more functionality in t.i.main Flamewars re: correct debian packaging will be left for later. def daemonize(): if os.fork(): os._exit(0) os.setsid() os.close(0) os.close(1) os.close(2) if os.fork(): os._exit(0) os.umask(0) Here's a quick thought about Debian packaging: add a script to ./bin "debianize". This script will take a .tap file and create a package named the same as the .tap file which relevant /etc/init.d/package and /var/lib/package/package.tap Perhaps even add it as a generic argument to mktap, so mktap --debian web --static /var/www will create the debian package. One caveat: version numbers. -- Moshe Zadka - http://moshez.geek (if you're not cool, http://moshez.org is still working)
On Tue, 7 Aug 2001, Moshe Zadka wrote:
daemonize() is cool, useful and should really be refactored out of twistd I really see no harm in providing more functionality in t.i.main Flamewars re: correct debian packaging will be left for later.
[snip] Daemonize's functionality is probably useful, however, there are a few things it doesn't take into account. Insofar as it's useful, most of twistd should probably be incorporated into it; any less is offering incomplete functionality. After all, this is about as platform specific as you get. If we have daemonize, then we probably want to have a similiar function for starting a Windows Service. Moreover, it would be good if we could detect which platform we're on, then do the appropriate thing for creating a daemon on that platform. This implies logging. "daemonize" won't work if you're still writing to standard output after you call it. So I'd say daemonize should at least take a logfile, and a function + varargs, and never return.
Here's a quick thought about Debian packaging: add a script to ./bin "debianize". This script will take a .tap file and create a package named the same as the .tap file which relevant /etc/init.d/package and /var/lib/package/package.tap Perhaps even add it as a generic argument to mktap, so mktap --debian web --static /var/www will create the debian package. One caveat: version numbers.
This sounds cool, with one minor caveat. I don't want to give windows users the impression that they're totally unsupported, especially any more than they already are. We should make plans to have similiar windows-ize scripts, and even if we don't have them, make it clear that we're not trying to make a debian-specific server infrastructure. Also, wouldn't this "debian" functionality be very similiar for redhat, mandrake, etc? Even solaris and MacOS X? "unixize" might be a better name for it. ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph
On Tue, 7 Aug 2001, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Daemonize's functionality is probably useful, however, there are a few things it doesn't take into account. Insofar as it's useful, most of twistd should probably be incorporated into it; any less is offering incomplete functionality.
No it isn't. It's offering *just* the daemonize functionality. You can have a higher-level wrapper *on top* of that which is portable, but daemonize() is useful.
After all, this is about as platform specific as you get.
Yes it is. I firmly believe in platform-specific APIs which are then wrapped in platform independent APIs. I don't want anything to restrict my access to the OS
If we have daemonize, then we probably want to have a similiar function for starting a Windows Service.
Yes, it would. This isn't an argument against daemonize.
Moreover, it would be good if we could detect which platform we're on, then do the appropriate thing for creating a daemon on that platform.
Agreed. But not with daemonize() -- with startService(....) which would call daemonize() on UNIX.
This implies logging. "daemonize" won't work if you're still writing to standard output after you call it.
Well, it closes FD 1, so it works well enough for that. Logging is left for a higher level API. As is writing PID files (which must be done after daemonizing but before getting into the main loop)
So I'd say daemonize should at least take a logfile, and a function + varargs, and never return.
No, that's startService, another useful API.
This sounds cool, with one minor caveat.
I don't want to give windows users the impression that they're totally unsupported, especially any more than they already are.
Fine, support them ;-)
We should make plans to have similiar windows-ize scripts, and even if we don't have them, make it clear that we're not trying to make a debian-specific server infrastructure.
*I* don't care if my server infrastructure is Debian specific.
Also, wouldn't this "debian" functionality be very similiar for redhat, mandrake, etc? Even solaris and MacOS X? "unixize" might be a better name for it.
No. Debian uses .deb packages. Maybe whoever does RPM chooses to redhatize or rpmize (I'm not sure: would she support SuSE? Mandrake?) Solaris uses its own unique wonderful format, as does MacOS X and AIX. I would be happy to put my /etc/init.d/ templates where everyone can use them. Everything else is distribution specific. It's not hard to have a hand install of a .tap if you have the /etc/init.d template. I want the Debian packages to be good enough that I'll feel good enough about uploading them to the official Debian archive, as well as maintainig a huge apt source on tm.com. -- Moshe Zadka - http://moshez.geek (if you're not cool, http://moshez.org is still working)
participants (2)
-
Glyph Lefkowitz -
Moshe Zadka