I have developed a dummy Launch Daemon that keeps writing something to the console(syslog) every 5 minutes. Now, I want to write an application that can communicate with this service. By communicating I mean that the user should be able to input the logging frequency(time). For eg, if the service is logging 'Hello world' every 5 minutes, the user should be able to change it to something else (say 2 mins) and the change should be reflected. Any idea on how I should proceed for developing the application and facilitate interprocess communication between the daemon and the application? Thanks.
There are several ways:
Have a config file for your application that contains the logging frequency and any other parameters you need. The daemon then parses the file on startup to get its parameters. The daemon also creates a SIGHUP handler, and when it receives a SIGHUP it re-reads the values from the config file. The part that the user interacts with then just gets new parameters from the user, edits them into the config file and sends a kill -HUP to the daemon's process id.
The daemon creates a second thread that creates a socket and listens for new parameters, when any arrive, the thread updates variables shared with its main thread which then continues with the new values. The part that interacts with the user then asks the user for new parameters and sends them to the agreed port - you can use nc or netcat to get started and then later code it in C++.
Related
I'm building a system that has 2 processes.
Process 1
This process is actually a Node.js program. This process is actually a Web Server handling the incoming request.
Process 2
This process is actually a C++ program.
Both the processes are started automatically at startup with help of rc.local
Now, for Process 1 there are some specific request that should be passed to Process 2.
For example, if Process 1 receives a post request at route /enqueue with a JSON body payload, Process 1 should stringify the JSON and pass to Process 2.
When Process 2 receives the JSON, it should kill a worker thread and start a new thread with that JSON to perform the actual task. The worker thread should be killed irrespective of whether the worker thread is still processing previous JSON
If both the processes were Node.js application, I could have forked Process 2 from Process 1 and used the following code.
process.on('message',function(message){
//implementation
}
...
process.send(data);
But my second process is a C++ app.
Any idea on how to implement it?
Note: Before flagging this question, please keep in mind I'm not looking for a full code. I just need the idea on how to do it.
You cannot use the Nodejs messaging/eventing facility for this purpose as it is specific to Node.
You will need to use the communications facilities of your operating system such as Unix, TCP, UDP sockets or an eventing system that both processes can communicate with, like Redis or ZeroMQ.
I have one deamon process which listen to the request from user and respond back.
While working on local system I execute it on terminal ./daemon. When user make request ./client from php page(executed by shell_exex() command) daemon process respond which some results. This is ok.
now I want to place this on ftp server. Php page whichc execute daemon process on button click event.
How could I make daemon process to keep listening on server continously? see daemon is c++ executable file.
One this is everytime I first execute shell_exec(daemon) but then purpose is lost. I want some way daemon process continously keep listening for the request!
Use daemon(), it does exactly what you want.
If this function is not available on your system, take a look at this tutorial which explains you how to rewrite the function.
When I run an application through a console, for example, $application start, how can I communicate with said application? So I can for example do $application load --/home/application/files/file.txt --warn=0 --notice=0 and that running instance of the application would react to this...
I do not want to keep listening to the console on the application side. I want to be able to close the console, reopen it, and still interact with the program.
The reason why I am doing this is because I want a master program that loads in different operations which it performs in the background. I want to be able to add operators, and remove operations.
Myself I have some experience with PHP and I know Apache has such behavior.
EDIT: After some comments of you guys, I concluded that I am required to use IPC. I have heard of this before but I never really understood how it works. After some Googling and the WikiPedia links you showed me I concluded that there are a sh-t tun of ways of handling IPC. I want to send packages of data to the main process, which one would be the best in my case? My personal favorite atm is a message queue but that only seems to work within the same process.
to be able to run application in background and have ability to close console where it was started, you may use nohup utility. then first instance of you app should create some ("well known") IPC resource (message queue, FIFO, whatever), so further instances will communicate over it with the first instance.
and it will be relatively easy, then to turn you app into a full functional daemon.
Since #LokiAstari pointed out, that you may don't have much experience with C++, I would recommend you to read: How to parse command line parameters.
I would then use a temporary file in /tmp to communicate with the main program, which run an infinite loop, waiting for modifications to the temporary file.
Personally I would do this in multiple stages.
As otherwise you are going to be trying to solve to many different problems at once.
What you are doing is writing a service (a long running application). Communication with the service by running a command usually involves running a different application that talks to the service (in apaches case the apache command starts the httpd service. Then subsequent commands talk to the httpd service).
But to get this up and running it is easier to go through a few steps first.
Write an application that on startup read commands from a directory
: So on startup you have a command directory.
: You open each file (in order execute the file if it is valid) then re-name the file to show it was done.
Modify your application to run as a continious loop.
All the loop does is look for events in job queue.
: if it sees them execute the job.
: If no job there then sleep for 10 seconds.
: On startup you just inject one job
-> : It reads the command directory and creates a job for each file.
-> : The file job executes the file then renames the file to show it is done.
Modify your service to use threading.
: Run the event loop in one thread.
: Use locks and semaphores so that added items to the queue is thread safe.
: When the application starts up you start the event loop (making sure it started then inject the job (as in 2). Then just waits for the event loop to finish (it will not).
Add a timer thread that fires very ten seconds to check the command directory
: All the timer should do is create a job and put it in the event queue.
: Now you don't need to inject a job at startup its the timers job.
Once you have all the above running you are ready to introduce a listener that will listen on a socket for indirect commands from another application.
: Doing all the above in one go to run the service is going to be long an error prone for a beginner. I advice you to fallow through all the steps above to get to this state then ask another question about how to do IPC.
: So add a new thread that listens on a socket (OK this is not the best technique but this is bootstrapping a beginner). When it receives input it creates a file in the command directory then places a job in the job queue.
You should now be able to test your command using the command line curl (or wget command) to send files to your service.
Once you have it working with curl.
You can write a standalone application that converts command line arguments into command files and sends them to your service.
Convert your application from using files to having all the information in the job object.
Thats it.
I have two applications one is a client the other is a server. The server launches the client as a sub thread. The client then outputs its commands via its standard out. The server waits for a command and responses accordingly.
Basically client server via the standard out.
For example:
client >> Move north
Server >> Your new location is {2,3}
client >> Move north
Server >> Your new location is {2,2}
client >> Shoot east
Server >> Projectile 66638 heading east {3,2}
The problem is that i don't know how to connect the two applications together so the server and read and response to the client application.
The reason that I would like to use the command line as the communication layer is that I want to keep the creation of the client as easy as possible.
Also there may be more then one client at a time, The clients should be able to communicate with the server interdependently of each other. (they should not be able to see each others communications)
Currently I am launching the application via the CreateProccess() function. This function makes it easy to set up the initial command line parameters of the application. just not the communication afterwards.
My Question is:
How does a server application that launches a client application as a thread, read/writes the clients standard output?
As the commenters above point out, Named Pipes (or sockets) is the way to go for this kind of solution, and it's two separate processes you probably want, not threads.
In Windows, the TransactNamedPipe() system call helps you accomplish what you want. It's ideally suited to sending commands to a server and waiting for the response, making it easy to create a client that performs something very similar to (synchronous) remote procedure calls to a server.
How Can I execute a function when Windows shutdown. Here is my scenario, I am mounting a drive using WNetAddConnection2 function in my application. Now I want user to set the option if the drive will be mounted on next system startup or not.
If he selects , not to mount on next startup , then I need to remove the drive using WNetCancelConnection2 , but this should only happen when user shutdown the system.
I can only think of only solution. Create a service which will check the user option and then decide whether to mount the drive or not.
Are there any other ways to go ahead with it?
If you have a main window (even an invisible one) that can process messages, you can handle the WM_ENDSESSION message.
See: http://msdn.microsoft.com/en-us/library/aa376889(v=VS.85).aspx
If you can make your app into a Windows service (or have your app communicate state with one that you provide) you can perform required actions on receipt of SERVICE_CONTROL_SHUTDOWN in your service control handler function. This would decouple your app that handles user interaction from the shutdown handling, which requires something to be running all the time (what if the user logs off?).
explorer.exe is the GUI process of windows which usually only gets shut down if Windows shuts down (exceptions have to be made for certain error conditions). You could listen on the WM_DESTROY window message for the process ID of explorer.exe and dismount then.
The way I can think of is to:
Register your program to auto Start up (when PC starts). Here's a tutorial on howto.
Store the user option (as mentioned above) in a repository or registry (if you know how). When your app would have started, you can read your registry and act accordingly.
For shutdown, your application will have to hook itself on a SystemEvent to detect shutdown (then you can act accordingly). Here's an example on howto (C#). For C++, you can listen to WM_ENDSESSION message.
I hope that my 2 cents can help you.