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
