Differences in controlling daemons & applications - bash

With respect to this excellent post:
What's 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 other means like querying it or restarting it (arch way):
# /etc/rc.d/daemon-name {start|stop|restart|status|...}
Could someone 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 will 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 1234)?
Thank you in advance!

# /etc/rc.d/daemon-name {start|stop|restart|status|...}
it is not a querying to the daemons directly. It is launching scripts by standart interface and these scripts in turn operate with daemon process by PID and signals. This scripts are creating during installation process of daemons-programs.

Related

Start/stop process in embedded linux

I have my own embedded Linux system on PocketBeagle board. I have developed a simple gpio application in C that issues an on/off command to one of the pins of the connectors of the board. The application is called gpio_aa6 and located at /root.
The first challenge was to find a way to launch my application automatically after booting the board. I found two ways to do that; the first was to add an entry to etc/rcS directory. This entry is a simple script file that launches my application. The second way was to edit /etc/inittab file and add an entry to that file (::respawn:/root/gpio_aa6). In both these ways my application was launched successfully: but I am still not sure if this is the right way to launch my application automatically.
Then I came to the second challenge, how can I stop my running application, as the respawn re-launches the application if it's terminated?
I am communicating with the board in two ways; via a serial communication (using screen terminal) and via web sever (root#192.168.42.2). I have tried to use Ctrl+C, Ctrl+Z, Ctrl+\, but couldn't stop the program from being continue running. Then I used command "killall" with killsignals -9 or -15, it seems that the program is interrupted but it's launched again directly after that.
My application is to run infinitely, but I need to stop it sometimes to update it and re-launch it again.
Is there any suggestion how to overcome this problem?
Thanks.
Both solutions you have used are correct. I personally prefer the option of adding an init script to /etc/init.d though.
I believe the behavior that you observe that you apparently can't kill the program is because you are starting your program from inittab, with the respawn keyword, which precisely tells the init program to restart your application when it exits. If you actually check the PID of your application, you will see that it changes everytime you kill it.
Therefore, I would recommend you to use an init script instead, with which you can implement start and stop actions. See ./package/lldpd/S60lldpd for a basic example in Buildroot.

The choice of architecture for a cli with a foreground process

I'm working under cli tool wich must communicate with another foreground always running processes. Tool will be used on windows|osx machines. I had a problem with the choice of architecture for it, here is my thoughts:
single binary, spawn daemon process[es] on start, communicate with signals or via loopback network. There are could be lot of headache with daemonization (have no clue how to daemonize windows process), daemon status checks.
multiple executable files. Drawback - not obvious how cli could find worker process(pid files? process name lookup?), probably deployment issues.
I will be grateful for any advice on the topic of my problem

Mac OSX LaunchDaemon run something on unload

I am new to Mac OSX and i am trying to develop a daemon (i am familiar with windows services, and trying to achieve about the same things).
What i did so far:
Managed to write a plist file in LaunchDaemons (i found out that those daemons run under system account, not user, just like a windows service with local system permissions).
I managed to make it run on startup, and run my simple hello world application that just writes something to a file every 10 seconds.
The problem is, when i unload the daemon with launchd, it just kills my process.
Is it any way to have the daemon either run something else on unload, or communicate to my process that it is shutting down, so i can perform an unload action in my code?
Thank you
The lifecycle of a daemon is documented by Apple and they describe how to handle Terminating Processes
If you're using Objective-c or Swift, you should be able to implement the applicationshouldterminate delegate method.
If you're not using Cocoa:
Non-Cocoa applications receive a “Quit Application” Apple event (kAEQuitApplication), as a courtesy, to give them a chance to shut down gracefully
Finally, since you're running a daemon (background process)
For background processes, the procedure is a little different. The loginwindow program notifies the process that it is about to be terminated by sending it a Quit Application Apple event (kAEQuitApplication). Unlike foreground processes, however, loginwindow does not wait for a reply. It proceeds to terminate any open background processes by sending a SIGKILL signal, regardless of any returned errors.
If the system is being shut down or restarted, it sends a SIGTERM signal to all daemons, followed a few seconds later by SIGKILL signal.
There's a discussion on handling SIGTERM here.

Can Xcode open an application without fork?

My question is just that. Is there a command in Xcode that uses a process other than fork?
There are other APIs to launch applications, but they all ultimately rely on fork()/exec(). There's no other way on UNIX to start a new process from userland than forking an existing process. You can install another task as a launchd job, then launch it by satisfying its start conditions - that doesn't directly use fork() (though of course it causes launchd to fork).

Monitoring a process in Windows

How can I monitor a Windows process and start it up if it is not running? I'd like to have something that starts up as a Windows service and can handle multiple processes.
EDIT:
Hopefully there's a ready to use library/component I can use and just tweak or configure instead of having to implement it from scratch. I know in the *nix world of two popular packages: god and monit.
You can create a Windows Service that just watches the current process list.
EnumProcesses provides the means of seeing processes running currently. There are many APIs available to start a new process, including:
system()
_exec()
WinExec()
ShellExecute()/ShellExecuteEx()
CreateProcess()
CreateProcessAsUser()
CreateProcessWithLogonW()
If you're using other languages/frameworks, they often provide their own wrappers around the above.

Resources