Modern daemon implementations can be run in a variety of ways, in a range of contexts. The daemon software itself can be a useful tool in environments where the associated traditional system service is neither needed nor desired. Unfortunately, common debian packaging practice has a tendency to conflate the two ideas, leading to some potentially nasty problems where only the tool itself is needed, but the system service is set up anyway.
How would i fix it? i'd suggest that we make a distinction between
packages that provide tools and packages that provide system
services. A package that provides the system service
foo would need
to depend on a package that provides the tool
foo. But the tool
foo should be available through the package manager without setting up
a system service automatically.
Here are some examples of this class of problem i've seen recently:
akonadi is a project to provide extensible, cross-desktop storage for PIM data. It is a dependency of many pieces of the modern KDE4 desktop. Its current implementation relies on a private instantiation of
mysqld, executed directly by the end user whose desktop is running.
This means that a sysadmin who installs a graphical calendar application suddenly now has (in addition to the user-instantiated local
mysqldrunning as the akonadi backend) a full-blown system RDBMS service running and potentially consuming resources on her machine.
Wouldn't it be better if the
/usr/sbin/mysqldtool itself was distinct from the system service?
Puppet is a powerful framework for configuration management. A managed host installs the
puppetpackage, which invokes a
puppetdservice to reconfigure the managed host by talking to a centralized server on the network. The central host installs the the
puppetmasterpackage, which sets up a system
puppetto make use of some of the functionality available in the package.
But this means that the central host now has
puppetdrunning, and is being configured through the system itself! While some people may prefer to configure their all-powerful central host through the same configuration management system, this presents a nasty potential failure mode: if the configuration management goes awry and makes the managed nodes inaccessible, it could potentially take itself out too.
puppettools be distinct from the
Update: puppet 0.25.4-1 resolves this problem with a package re-factoring; the tools are in
puppet-common, and the
puppetpackage retains its old semantics of running the system service. Looks good to me!
The Monkeysphere is a framework for managing SSH authentication through the OpenPGP Web-of-Trust (i'm one of the authors). To ensure that the package interacts properly with the OpenSSH implementation, the
monkeyspheresource ships with a series of test suites that exercise both
This means that anyone trying to build the
monkeyspherepackage must pull in
openssh-serverto satisfy the build-depends, thereby inadvertently starting up a potentially powerful network service on their build machine and maybe exposing it to remote access that they didn't intend.
Wouldn't it be better if the
/usr/sbin/sshdtool was available without starting up the
Here are some examples of debian packaging that already understand and implement this distinction in some way:
apache2.2-binis distinct from
- Debian's apache packaging
to split the apache tool into a separate package (
apache2.2-bin) from the packages that provide an apache system service (
apache2-mpm-foo). So apache can now be run by a regular user, for example as part of
git-coreis distinct from
git daemonsubcommand, which is a tool capable of providing network access to a git repo. However, it does not set up a system service by default. The
git-daemon-runpackage provides a way for an admin to quickly set up a "typical" system service to offer networked git access.
vbladeis distinct from
vbladeoffers a simple, powerful utility to export a single file or block device as an AoE device.
vblade-persist(disclosure: i wrote
vblade-persist) provides a system service to configure exported devices, supervise them, keep them in service across system reboots, etc.
Tools are not Services: a Proposal
Let's consider an existing
foo package which currently provides:
- the tool itself (say,
- sets up a system service running
foo, including stock
foodaemon configuration in
/etc/foo/*, startup scripts at
/etc/init.d/foo, service configs at
I suggest that this should be split into two packages.
contain the tool itself, and
Depends: foo-bin) would
contain the service configuration information, postinst scripts to set
it up and start it, etc. This would mean that every instance of
apt-get install foo in someone's notes would retain identical
semantics to the past, but packages which need the tool (but not the
service) can now depend on
foo-bin instead, leaving the system with
fewer resources consumed, and fewer unmanaged services running.
For brand new packages (which don't have to account for a legacy of
documentation which says
apt-get install foo), i prefer the naming
convention that the
foo package includes the tool itself (after all,
it does provide
foo-service sets up a standard
system service configured and running (and depends on
This proposal would fix the problems noted above, but it would also
offer some nice additional benefits. For example, it would make it
easier to introduce an alternate system initialization process by
creating alternate service packages (while leaving the tool package
alone). Things like
become actual contenders for managing the running services, without
colliding with the "stock" services installed by the bundled
The ability to create alternate service packages would also mean that
maintainers who prefer radically different configuration defaults could
offer their service instantiations as distinct packages. For example,
foo daemon (
foo-service) versus a separate instance
foo daemon per user (
foo-peruser-service) or triggering a
One negative side effect is that it adds some level of increased load on
the package maintainers — if the service package and the tool package
both come from the same source package, then some work needs to be done
to figure out how to split them. If the tool and service packages have
separate sources (like
vblade-persist) then some
coordinating footwork needs to be done between the two packages when any
incompatible changes happen.
Questions? Disagreements? Next Steps?
Do you disagree with this proposal? If so, why? Unfortunately (to my mind), Debian has a long history of packages which conflate tools with services. Policy section 9.3.2 can even be read as deliberately blurring the line (though i'd argue that a cautious reading suggests that my proposal is not in opposition to policy):
Packages that include daemons for system services should place scripts in
/etc/init.dto start or stop services at boot time or during a change of runlevel.
I feel like this particular conflict must have been hashed out before at some level — are there links to definitive discussion that i'm missing? Is there any reason we shouldn't push in general for this kind of distinction in debian daemon packages?