Hi all,
This is a more generic discussion of definitions of service,
daemon,script, etc. Definitions are important because:
1. A word with multiple definitions has no definition at all.
2. Technology is much easier to learn and understand if definitions are
solid.
It's my impression that there was very little ambiguity in these
definitions before the advent of systemd. Just reading the "What is
it?" section of djb's
https://cr.yp.to/daemontools.html :
=================================================
"daemontools is a collection of tools for managing UNIX services.
supervise monitors a service. It starts the service and restarts the
service if it dies. Setting up a new service is easy: all supervise
needs is a directory with a run script that runs the service."
=================================================
I think most people would interpret djb's words as implying that a
service is a process, possessing its own PID, that's intended to run
for extended time periods. Based on the older term "client/server", it
might be reasonable to equate the words "service" and "server", and we
all know from way back in the early 1990's that a server is a process,
lacking user interface or ongoing user intervention, that takes
requests from other processes and gives them what they ask for, subject
of course to rules.
Daemon has always meant what's described in the preceding paragraph.
A process is a running computer program possessing a PID (in UNIX). It
might or might not have a user interface, and might or might not keep
running until deliberately stopped.
As far as I know, the term "program" has two distinct meanings,
depending on context:
1. A process
2. A hunk of source code capable of defining and/or creating a
runnable process. This ambiguity has existed since at least as early
as the early 1980's, and as far as I know has never been problematic.
I've heard the term "script" used many different ways. Some insist
only bash, /bin/sh, dash, ksh, csh, execline, etc produce scripts.
Others include Perl, Python, etc. Others include all interpreted
languages, although these days with Just In Time compilation,
"interpreted language" is a fuzzy term. On a personal level, I view
this as a distinction lacking a difference: One can perform almost any
task (perhaps very badly) from either bash or C. I personally call all
of them "programs".
Getting back to the term "service", I think it was generally understood
accurately on an intuitive level until the advent of systemd. I'm no
authority on systemd, but my impression is that systemd uses the term
"service" not only for something like sshd, but also for a tiny
programs whose normal operation is to set up some config and then exit.
Two examples would be the process reading /etc/fstab and doing the
corresponding mounts, and the process to set up all the networking
links, addresses and routes. This is a major departure in definition.
I guess the motivation behind this is the very real need to respect
dependencies. You'd better not start NFS or your database server until
the network is functioning. My understanding is that systemd
accomplishes this with "Provides" (via Targets and Aliases) and
"Requires", "After", etc. So systemd treats config setup processes the
same as daemons, which is fine, but I wish they didn't call config
setup processes "services", because this is confusing.
Anyway, hopefully this explains my confusion.
Thanks,
SteveT
Steve Litt
http://444domains.com
Received on Sat May 16 2026 - 16:47:56 CEST