Python Daemon Packaging Best Practices

Question

I have a tool which I have written in python and generally should be run as a daemon. What are the best practices for packaging this tool for distribution, particularly how sho

Answer 1

"generally should be run as a daemon?"

Doesn't -- on surface -- make a lot of sense. "Generally" isn't sensible. It's either a a daemon or not. You might want to update your question.

For examples of daemons, read up on daemons like Apache's httpd or any database server (they're daemons) or the SMTPD mail daemon.

Or, perhaps, read up on something simpler, like the FTP daemon, SSH daemon, Telnet daemon.

In Linux world, you'll have your application installation directory, some working directory, plus the configuration file directories.

We use /opt/ourapp for the application (it's Python, but we don't install in Python's lib/site-packages)

We use /var/ourapp for working files and our configuration files.

We could use /etc/ourapp for configuration files -- it would be consistent -- but we don't.

We don't -- yet -- use the init.d scripts for startup. But that's the final piece, automated startup. For now, we have sys admins start the daemons.

This is based, partly, on http://www.pathname.com/fhs/ and http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/Linux-Filesystem-Hierarchy.html.