0

With respect to this excellent post:

https://stackoverflow.com/questions/958249/whats-the-difference-between-nohup-and-a-daemon

I would like to ask the following:

After launching an application from my terminal, the application keeps running either in the background or the foreground and the only thing I can do to interact with it is by sending it signals from my terminal (given that stdin is still in place).

However, after a daemon process is launched, I realized that it can be controlled with extra means (apart from signals) like querying it with flags like below (arch-way):

# /etc/rc.d/daemon-name {start|stop|restart|status|...}

Could someone please explain to me if that feature is built-into the general "daemon framework" and applies to every daemon process as a special feature or is it just a provision that processes designed to run as a daemon have to handle internally?

And to add more to the matter, how on earth are we able to "control" daemons from the terminal using their name (i.e. sambad stop) while applications always have to be referred using their name (i.e. kill -9 12345)?

Thank you in advance!

Improve this question

2 Answers 2

Reset to default
1

If I understand the question correctly, when you're using sambad stop, it's referred by PID number as well, which is stored in /var/run/ directory (or other depending on your system). The file is created when you do start.

This feature is not built-into that deamon. If you edit /etc/rc.d/daemon-name, you could see it's a simple bash script, which running the process with specified parameters (arguments can be defined in that script on Linux, or in /etc/rc.conf on Unix). You can write your own daemon-name start and stop script.

Basically:

  • start runs the process from the terminal (process automatically know that it should run in the background, sometimes there is special argument for it like -d),
  • stop it's doing kill -9 cat /var/run/daemon.pid,
  • restart it's doing kill -HUP cat /var/run/daemon.pid,
  • status it's doing something like: ps cat /var/run/daemon.pid.

Also there are different communication methods than sending the signals using unix sockets. In example, you can control the processes by sending dbus messages. See: man dbus-send

Following command will list all your unix sockets:

netstat -lp --unix

You can filter it by dbus by:

netstat -lp --unix | grep -w dbus

By executing dbus-monitor you can see how different processes can communicate with each other.

Here is some example of sending the message to the other service:

dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames

Read some useful articles:

Improve this answer
5
  • Thanks. This is exactly what I was confused about. Now, since daemons are pretty much mere processes controlled by a script (with some extra properties), could you please specify if the functionality of a daemon (or process) in general can be altered during runtime by summoning its pid with an appropriate flag? (not to confuse with server daemons which listen to specific ports)...
    – stratis
    Commented Jul 29, 2012 at 15:35
  • What do you mean by altering it during runtime, can you give me some example? There are different signals (See: man sigaction) which you can send to alter the process. You can stop the process by SIGSTOP, or SIGCONT to resume it, on Unix machines you can also get some additional info using SIGINFO signal.
    – kenorb
    Commented Jul 29, 2012 at 16:24
  • Yes. That's exactly the job of the signals. The "problem" is that in theory, after an application/daemon is launched, you have no control over it -APART from sending the usual set of signals-. However as an example, I recently read this post about a new text editor called "Sublime Text" wesbos.com/sublime-text-2-tips which suggests that we can control the editor with additional means using its included cmd tool which in turn allows you to append files to a running instance of the main editor's window...How is that possible since all we can do about already running apps is signal them?
    – stratis
    Commented Jul 29, 2012 at 18:43
  • 1
    I think it depends of the applications, it could create some local unix sockets (See: netstat -na), standard TCP/IP sockets, or some kind of semaphores (See: ipcs –s), message queues, etc. which are used for communication between the processes. Run as well: lsof -p PID, to see all the handlers used by the process.
    – kenorb
    Commented Jul 29, 2012 at 20:14
  • I just realized that my question mounts to if and how inter process communication can be achieved...and since I was missing that bit and only knew about plain unix signals which don't carry any sort of information, I eventually got confused. Thank you all for your answers.
    – stratis
    Commented Jul 30, 2012 at 19:39
1

Most of the functionality is not built into the daemon, but into the init scripts. In /etc/init.d/sambad there will be code to keep track of the PID when it's started and signal it when it needs to stop. The init scripts are usually more specific to the distribution than to the daemon in question since system startup and service administration is one of the main areas that Linux distributions use to distinguish themselves.

The ability to reload a config file without killing and relaunching the daemon is the only one of these actions that needs any significant amount of code written inside the daemon itself.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .