order of operations when daemonizing

[Ben Finney]

On 20-May-2014, Ethan Furman wrote:

> I just started using the daemon module, and I have a few questions:

Welcome, and thank you for using ‘python-daemon’.

Many of these questions are addressed in PEP 3143, the document
describing the rationale and design for daemonisation in Python
<URL:https://www.python.org/dev/peps/pep-3143/>. Others are addressed
in the FAQ document provided with ‘python-daemon’.

> 1) Why are DaemonRunner and DaemonContext two different things?  I would have
>    thought that part of being a "well-behaved daemon" included stopping and
>    restarting.

See the question “How can I run a service communicating with a
separate daemon process?” in the FAQ document (‘doc/FAQ’ in the source
tree).

The daemon should normally run as an unprivileged user. So the service
runner – which is commonly some part of the OS like the SysV Init or
the SystemD service runner, but could alternatively be the daemon
program running as root before opening the DaemonContext – needs to
take care of starting and stopping and handling a PID file, and other
privileged operations. So those need to be separate processes.

> 2) Why does DaemonContext lose privilege and detach before setup is
> complete?

Because that's an essential part of the contract. On successful return
from ‘DaemonContext.open’, the process is running as a well-behaved
daemon. It's an atomic operation.

>    a) I can't create a pid file in /var/run

Essentially, creating the PID file and socket files and log files,
etc. is the job of whatever privileged process starts the daemon
(which may be the same program in the time span before it drops root
privilege). Those files are then passed to the DaemonContext.open
call.

The API for ensuring a file remains open is the ‘files_preserve’
option. The PID file is an excellent candidate for that option.

This topic is a source of Frequently Asked Questions, not only about
‘python-daemon’ but about daemons in general. There are multiple,
conflicting, conventions around how to handle PID files; so the
‘python-daemon’ library delegates the decision to the programmer.

If someone could write an entry for the FAQ document I'd appreciate
it.

>    b) I don't see any errors because it's already detached by the
>       time this happens

Setting up a log stream is, again, something that needs to be done
prior to starting the daemon; and the log stream's file descriptor can
be preserved with ‘files_preserve’.

>    c) If I use the wrong pid class […] yet nothing is happening from
>       the daemon that should be happening.
>    d) if the daemon is already running there is no notice of this […]

More specific information about these would be helpful. Set up logging,
preserve the log through the ‘files_preserve’ option, diagnose this in
more detail, and start a new thread to discuss the issue.

> I'm happy to help with development, I just need to figure out
> bazaar. :)

“Bzr Init” <URL:http://bzrinit.com/> is a user tutorial on Bazaar. The
Bazaar documentation also has a “Centralized Workflow Tutorial”
<URL:http://doc.bazaar.canonical.com/bzr.2.6/en/tutorials/centralized_workflow.html>
which describes the workflow we're using.

-- 
 \      “We suffer primarily not from our vices or our weaknesses, but |
  `\    from our illusions.” —Daniel J. Boorstin, historian, 1914–2004 |
_o__)                                                                  |
Ben Finney <ben at benfinney.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/python-daemon-devel/attachments/20140521/fdbf1394/attachment.sig>