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.
Related
Is there some way to launch a process in non-elevated way from an elevated one. My setup is launched elevated and when it finalizes, it will just launch the main application. Because the setup is elevated, the main process will be elevated as well which is not desirable. What is the best solution to this?
That's a problem, Vista/Win7 don't appear to have an API to obtain the unprivileged user token you need to call CreateProcessAsUser(). The only solutions I've found involve using the task scheduler to launch the program. That doesn't strike me as very practical.
An easy solution that jumps to mind is to use a small non-elevated helper process. It can in turn launch the elevated setup process and wait for a confirmation from that one to launch the non-elevated one. The handshake is simple enough to do this with a named mutex.
The only way to do this without hacks is to have two processes (Can be implemented in the same .exe)
Instance A starts Instance B with ShellExecute and the runas verb.
B does the installing, when its time to start your app on the "finish page", it uses some form of inter processes communication (RPC, shared memory+events etc) with A telling it to start a process on its behalf.
This seems like a nice way to do it, provided you don't care about situations where the Shell is not running (e.g. possibly some Terminal Services application-only setups, perhaps, though I'm not sure):
http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you-part-2-how/
It gets an interface to Explorer.exe, which should be running in the user's normal context, and asks Explorer to execute a command in its behalf. This is done just using simple, documented COM interfaces and without having to mess around with process tokens or code/DLL injection.
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++.
I am searching for a way to close a process running under any user by a windows service running under the system account. I've nearly tried everything but I could not find any solution except killing the process.
Why can't I kill the process?
I can't kill the process uses a tray icon. If I kill the process, the tray icon won't disappear.
What I've tried so far
I've already tried to use global eventhandles (did not work because the child process got extremely laggy).
I also tried to use PostMessage/SendMessage to communicate with the process. That solution did not work because a windows service can not interact with any user interfaces,...
I found another question (here on stackoverflow) which describes exactly my problem: Close a child process from a windows service.
This question does not contain a nice solution.
First of all I don't use C++ instead of C#. The next problem is, that the child process uses a mouse hook. So it has so run very fast without many overhead. Otherwise it would get laggy which would mean, that the mouse would lag on the whole system.
So is there really no simple solution to close a process from a windows service?
A service can use SetProcessWindowStation() and SetThreadDesktop() to attach to the interactive desktop of the target process before then sending messages to the target process.
Alternatively, the service can use CreateProcessAsUser() to run a new process in the same session as the target process, and then that process can send messages to the target process.
I want to make a tool that runs on win32 to monitor our online game servers. The servers actually are .exe files. I need to know whether they have crashed so I can restart them. Therefore, the tool will have 2 main features:
Frequently check a list of the server programs to see whether they are running or not
Reopen the executable of any server that has crashed
Does anyone have any idea or knows an API to start with?
If you're in Win32, you can start out with C# using System.Diagnostics
using System.Diagnostics;
Then get a process list:
Process[] processlist = Process.GetProcesses();
foreach(Process theprocess in processlist){
Console.WriteLine(“Process: {0} ID: {1}”, theprocess.ProcessName, theprocess.Id);
}
And from there it's up to you what you want to do with the info.
Game servers should produce logs. You should make a service / cron job to monitor the logs. Depends on the contents of logs, your service should act respective actions, e.g. restart service, trigger alarms, etc.
I realize that this is not exactly what you asked for, but what about doing the monitoring with a fully-fledged monitoring tool such as Nagios? You would of course have to "teach" the monitoring tool about the processes that shall be monitored but you would also profit from its more advanced functions. In the case of Nagios, for example, these would comprise automatic e-mail notifications, an online dashboard of process status, notifications via SMS etc.
You should start the game servers using CreateProcess or similar in the win32 api.
You will get back a process handle in the lpProcessInformation parameter.
You can use WaitForSingleObject to WaitForMultipleObjects to wait until that handle is notified which will happen when the process terminates for any reason.
I have a single thread that I'd like to run as an administrator in my application. The rest of the application I can happily run as the default user level (asInvoker). Is this possible? I notice there is an "ImpersonateLoggedOnUser" function. Can I somehow use this to log the administrator on and then get the thread to impersonate that person?
It seems as though this ought to be something pretty trivial to do ... but there doesn't appear to be any obvious way to do it. Can anyone help me out?
Edit: So if I have to fire off a seperate process is there any way I can CreateProcess a new process and have it launch from a specific entry point. I can, of course use command line processing to do it, but i'd really rather I could stop the user from entering the command line and starting an unclosable process!
No, elevation is per process, not thread.
If the rest of the application has to run non-elevated, you could run yourself elevated with some parameter (myapp.exe /uac "ipcparamhere") and use some sort of Inter-process communication to communicate back to the "main instance" of your app. (If the elevated process only performs a simple operation, you could probably check for success by using the exit code of the process)
This is not possible. You'll need to gain admin privileges by including a manifest in the app. Google "requireAdministrator" to find the manifest you'll need. Your user will probably quickly tire of doing this over and over again, your best bet is to spin-off the task that requires these privileges into a separate process. A service for example.
You can launch a separate exe and have a manifest on it saying it requires administrator. Then be sure to launch it with shell execute, which uses manifests, and you're all set. As a thoughtful touch, put a UAC shield on the button that kicks off that thread. (Send it a BCM_SETSHIELD message if you're doing this all by hand.)
You can decided whether you want a visible window or not on the separate process. Meanwhile the user can still drag and drop into the main app.