I'm reading the thread at http://www.linuxquestions.org/questi...-linux-814229/, and have a couple of questions.

tommylovell writes:

and then

I'm a bit confused about when a daemon is not a service.

He says that a service is controlled by a 'rc startup' script, which I assume are the scripts in the /etc/rc.d directory. These can be manually controlled via the 'service' command (further lending support that a 'service' is controlled via a 'rc startup' script). My understanding is that this scripts are _also_ run by the bootup sequence, which processes the inittab file at the beginning.

So a 'service' is started by a 'rc startup' script, which itself is run either at initialisation or via the 'service' command.

So how can you have a daemon (by these definitions that are not services)? The author alludes to this

A daemon is a process that is not associated with a terminal. It's just running and doing whatever, with no user at a keyboard controlling it.

A service is something that responds to "requests for assistance" from other people or processes. Say, a webserver for example. You go to that website and it "serves" you by displaying the webpage that you requested.

Most "services" are provided by "daemon" processes. But a "daemon" process does not have to provide a "service", it could do other things instead.

3 members found this post helpful.

So it's not so much how it's brought up, but rather what it does once it's brought up... consequently does that mean that the quotes in my post are misleading?

Do you know why the poster says that starting from /etc/inittab is inadvisable? Is it because httpd would start along with system startup, which is not what is desired here?

A daemon process can be started in many different ways. That is all the post you quoted was trying to explain. It was not misleading IMHO, you just may have misinterpreted it. Which particular route was used to start a process has no bearing on whether that process becomes a daemon process or not. You can start daemon processes manually, from the commandline, if you want. Or you cn start a process normally, and that process daemonizes itself, without you manually having done anything to initiate the daemonization.

As far as the adviseability of working directly in /etc/inittab: If your system even has an /etc/inittab, usually what you find there is high level system stuff. For example, you will find entries in /etc/inittab that run the /etc/rc*.d scripts (if you system even has those). Typically, users do not add things to /etc/inittab directly, they add rc*.d scripts instead. So to start a webserver, you normally find an /etc/rc*.d script to do that, not a specific webserver startup entry in /etc/inittab. On some systems, /etc/init scripts replace/augment /etc/rc*.d scripts. And typically, /etc/rc*.d scripts are actually symlinks to /etc/init.d scripts. Note: There is a difference between /etc/init and /etc/init.d. Similar things are accomplished in either place, but they are different.

1 members found this post helpful.

i always thought that a daemon was a type of service that spawns a new sub-process for each call to that service.

I believe you are confusing a "forking" server and/or a "multi-threaded" server with a daemon. Forking servers spawn child processes to handle a client, multi-threaded servers do similar things using threads rather than child processes.

Your post is quite enlightening. I hope i'm not going too far off topic, but what exactly is the difference between /etc/init.d and /etc/init?

1 members found this post helpful.

Although this makes sense, the post and other material imply that, at least in some circumstances, a Linux 'service' and 'daemon' are different depending on the method used to start them (rather than what they do once started). Notably at http://magazine.redhat.com/2007/03/0...linux-daemons/

Also, according to this definition of a service, not all Linux services are daemons (http://www.comptechdoc.org/os/linux/...lservices.html

All of this is probably a matter of definition.

Thanks for the response, they have definitely helped.

The term "service" has a lot of different definitions. A "daemon" is one way of implementing a service. So, "service" is a very general term that has different meanings depending on where it is used. The term "daemon" is more specific, applying to programs in Linux that are not associated with a specific terminal or user logon session.

In Linux there is also a historical meaning for the term "service". A lot of Internet related services are started and managed by a daemon called "inetd". Traditionally those things were called "services" to distinguish them from "daemons" that were separate from "inetd". Examples of "inetd" services are telnet and (some versions of) ftp. So when someone is referring to services they may be referring to things that are started and managed by "inetd".

In Windows, the term "service" is very well defined. A service is a particular kind of program designed to be started by the Windows service manager. Services appear in the list of services shown by the control panel. Services have to provide software functions to process the requests from the service manager such as "start", "stop" and "status".

Windows also supports normal "console tasks" that can be thought of as a "daemon". The name "console task" is misleading. It just means any task that does not use the Windows graphical interface. Console tasks don't necessarily communicate via the text console (command prompt window) though they can.

You will often find that software modules or programs that all provide similar functionality (for example printer functions) will be implemented as a class of "services" that all use a similar interface and are controlled by the same manager program. Thus the term "service" can very specifically mean a particular kind of module or program with a well-defined set of functionality. For example those programs would be called "printer services".

In networking, the term service also has a more specific meaning. A service is a program that accepts connections, listening on a well know (pre-defined) network port. Clients establish connections to services and then send requests. The service responds to the requests.

1 members found this post helpful.