We have several apps that run on a Windows 2003/2008 server. Some of these apps are Java JAR files that are kicked off with a Scheduled Task using a app.cmd file.
Others are "big ones" like SQL Server and IIS.
I'd like to write an app (or service, actually) that simply monitors those programs and sees if they are running or not.
This is a little beyond what I've done before. Oh, this needs to be written in C#.
I was thinking of some type of "heart beat" pattern so that every few minutes, I check if the thread is running (again, new advanced threading) and if so, send out an "All's OK" message (using SMTP or something).
Any tips where to get started?
Thanks for any suggestions.
You can use Process.GetProcesses():
Use this method to create an array of new Process components and associate them with all the process resources on the local computer.
You should probably handle each application on a case-by-case basis, for exaple although you could just check for the existance of the SQL Server process you would be better off running a query that (for example) checks for the existance of a given database in the server.
Similarly you could run a simple HTTP request against an IIS server to check to make sure that the permissions are set up correctly etc...
Obviously the way that you test your Java processes would depend on what they do, although you could still just check for to see if the process is running (be aware that if they are running as a service they may be running inside one of the svchost.exe processes - this doesn't apply to scheduled tasks though).
Related
I am trying something new to me, so I don't have the vocabulary to express my questions in any sort of domain specific language.
I am currently mind mapping a tool I would like to build. The function of this tool is to execute many long running tasks and log results to an remote database. This is most similar to Jenkins build and test functionality. Unfortunately, I don't think I can use Jenkins since these are tests executed on real live custom hardware with a lot of IO operations with other hardware resources.
It would almost certainly be run on a server, so it's headless. I generally build desktop tools with a UI to execute similar tasks in a windows desktop environment. When I want to communicate to the user what the tool is doing I simply create some UI elements to display status.
In this environment there would rarely if ever be a person looking at it work. If I DO need to debug something while running, or just want to check the status my immediate thought is log files. However, they are pretty cumbersome to watch in real time.
I would like to be able to make requests of the task runner from the command line in the same way I git status. My current thought is to register my command (like git) on PATH. I could have that command connect to a named pipe that my long process is connected to/monitoring and relay the user's request. (I have never used named pipes before, but it seems like a standard way to have processes communicate?)
This solution requires three "layers":
The command that is on PATH that can parse/accept/reject the user's request and then forward it along.
The long process manager that listens for user requests and monitors long task execution.
The task executers themselves.
Are there other approaches? Am I reinventing the wheel? Links and resources are greatly appreciated!
How can I create a long running task that listens to requests from the
terminal? (Not just asking for input)
You can use sockets for inter-process communication or pipes.
Am I reinventing the wheel?
It depends on the use of that program. ie what are the tasks that are running.
For ex: If you are creating a version control system then yes, git already exists
If not then no. You are simply creating a program or application or website that use multiple threads. Multiple threads are provided by the hardware (CPU) and Operating system. You Interact with these threads using the programming languages.
Applications or programs can be single or multi threaded.
For example github:
When you vote on an answer you are basically creating a request that is received by a program running on a server which creates a thread to update the vote count in the database. In the meanwhile if someone else also vote on an answer a similar request is sent and handled maybe by the same server on another thread. This server is still listening for request and in the same time executing tasks (updating the vote count in the database)
Note: This example is simplified, just as an example
For running tasks in the background and still having a functioning UI or request listener, you require multiple threads. One thread for UI, one or more for handling requests, and the rest for running those background tasks and writing to the logs.
Note:
when dealing with threads thread safety and shared resources between threads are important.Also programs can also use more than multiple processes, but multithreading was introduced to fix some of the overhead of using multiple processes (related to thread safety and shared resources).
In your case, If the log files are in a database, then concurrency is access is handled by that database.
But in case the log file is a local file on the system, then writing and reading from the log requires handling the multiple threads access to that one log file. That is where thread safety and shared resources is used.
Note that the below is a simplified comparision:
In case of a local application which uses multiple processes:
This application is like a network of processes, with each process
running a certain program.
Process 1 might render the UI, Process 2 might write to a log file,
etc...
Pipes, signals, or other operating system technologies are used to
send messages and communicate between these processes (Programs).
Ex: when a user press "Write log" button, process 1 communicates with
process 2 (using the communication methods from above) to tell
process2 to write to that log file.
In the case of a web app:
processes becomes computers connected over the network(or servers
running on a host) Operating system technologies becomes Network
communication like HTTP request and responses, JSON, xml, etc...
So This application is like a network of computers (servers)
located in different locations, with each computer running a certain
program.
Computer 1 might render the UI, computer 2 might write to the
database, etc...
Network communication technologies are used to communicate between the
computers or servers over the internet. Ex: when a user press
"Write log" button, Computer 1 communicates with Computer 2 (using the
communication methods from above) to tell Computer to write to that
database.
A host is a computer hosting (running) a program. This program is usually called a server. (The host provides services)
I have a requirement that a Windows Forms C# .NET 2.0 program running in user-space (not a service) must always be running. As I'm not infallible and make coding mistakes, I wanted to know of any extra safeguards I could use to ensure this requirement is met. The things I've been thinking of are TaskScheduler to check it every 5 minutes, A stub watcher or a secondary process. Are these good / bad ideas?
Thanks,
Richard
EDIT: The reason I didn't use a service (the obvious and sensible answer!) was the program runs in a kiosk type environment and has has a heavy GUI component. The service option didn't work well across Windows 2000 - W7.
EDIT: The second reason not to use a service was the app needs internet access and on some of our customer sites, proxies are set up to only allow specific users (not the local system account) so it would be tricky to ensure access if multiple users log onto the machine.
Task scheduler is a cheap solution for this which does work. I use this to keep our Perforce Proxy server running (had some issues with the service), and so far there's been no problems - though now I've said that the server's probably exploded!
However, the most complete solution is a Windows service which invokes your app. You can make that service catch error return codes from the app, restart it on failure and notify you by email, which may help you diagnose and fix those issues. I think the Task Scheduler does something similar but it won't be able to provide as much insight into your application as a custom service.
If you're unsure of how to do that, then something like this should work:
http://www.codeproject.com/KB/install/csharpsvclesson1.aspx
There are three approaches that you can take:
Heartbeat Message.
A heartbeat is useful in a distributed application and is simply message that is sent (from let say a client to server) to confirm that it is still healthy/running.
Manager Process
A stub program, implemented as either a user process or a service. It launches the main application, monitors any unhandled exceptions, reports errors, and restarts on failure.
An exception guard on the entry point.
A try-catch-all in the application entry point.
I would recommend either of the first two options; the third option, the try-catch-all, is a particular nasty hack for the lazy and inexperienced programmer (IMHO).
I have successfully used both heartbeat and manager process in a large distributed application.
UPDATE
As for ready-to-go™ restart managers, take a look at the Windows API Codepack as discussed in Emmanuel Istace blog post (http://istacee.wordpress.com/2013/09/21/automatic-recovery-restart-in-net-application/).
You can install the package from https://www.nuget.org/packages/WindowsAPICodePack-Core/
Are there situations that we should use a windows service ?
I am building a client-server project (c#) and the server supposed to work alone without any user so someone advised me to use a windows service to run the server, is this right ? or there are a better solutions ?
Windows services are normally used when an application needs to continuously run. For example if they need to:
Wait for incoming requests. (Like through remoting or wcf)
Monitor a queue, file system etc.
If a program just needs to run periodically, like once a day. It is normally easier to create a scheduled task.
In your situation I would use a service for the following reasons:
You don't need to have a session running. This is good for security, and also reduces overhead on the server.
You get some of the managment commands built in for free
Start
Stop
Pause
Continue
You can handle server events such as shutdown.
Windows service can start running as soon as the machine is powered up, which makes ideal for running as a server, http server for example. No one is required to login.
You should create a Windows Service to run code in the background, without user interaction.
For example, a Windows Service will run even if no-one is logged on.
Any server that accepts connections (such as a mail, web, or FTP server) should usually be a Windows Service.
Well, a Windows Service provides a full framework for your application to work and to remain active while you want it to, so I think its ok.
Windows services are the right thing to use for something that should run all of the time, whether or not a user is logged in.
If you need something to run without an active user logged in, you need to use a windows service.
When you need the application to start running even when no one has physically logged into the machine, which is common with server machines, a service is a good candidate in this case. Especially because the service can be configured to auto start, which means the service will start when the machine is rebooted withut human intervention.
If however you are wanting to host web services (WCF) while a service is an option, you might consider hosting in IIS, this relieves you of writing the actual hosting code etc.
I need to implement a background process that runs on a remote windows server 24/7. My development environment is C#/ASP.NET 3.5. The purpose of the process is to:
Send reminder e-mails to employees and customers at appropriate times (say 5:00PM on the day before a job is scheduled)
Query and save GPS coordinates of employees when they are supposed to be out on jobs so that I can later verify that their positions were where they were supposed to be.
If the process fails (which it probably will, especially when updates are added), I need for it to be restarted immediately (or within just a few minutes) as I would have very serious problems if this process failed to send a notification, log a GPS coordinate, or any of the other tasks its meant to perform.
Implement your process as a Windows service.
For a straightforward example of how
to code a Windows service this in
.Net see http://www.developer.com/net/csharp/article.php/2173801 .
To control what happens should the
service fail configure this through
the "Recovery" tab on your service
in services.msc. (see image below)
For higly critical operation you
might look into setting up a server cluster for mitigating single
server failure (see http://msdn.microsoft.com/en-us/library/ms952401.aspx ).
(source: microsoft.com)
You need a Windows Service. You can do non-visual iterative operations in windows services.
Another alternative is to create a normal application and run it on a schedule. Your application is run at certain times a day to perform its actions, depending on how often you need to log GPS coordinates and send reports. If your service doesn't need to run constantly this is usually the recommended approach, as services are supposed to be limited to always-on applications.
As well as being a service, you might want to run on a cluster, and make your service known to the cluster management software.
You can create Windows Service (server programming on Windows) or use scheduler to periodically execute a task.
Depending on the requirements for the high availability, program can be installed on a fail-over cluster where there will be other server (passive node) started and quietly waiting as a hot-backup if the first (active node) dies. This is wide topic. Start with High availablity on Wikipedia.
In my experience if you need to run something 24x7 you need to have (one or more) watchdog process to verify that your service(s) are running correctly. Just relying on the normal service framework cannot guarantee that the program is working correctly - even if it looks like it is running. The watchdog program (which also is a service) can query the service automatically e.g. posting messages checking response times, querying for statistics and so on - when it detects problems it can restart the service (or do some other fail-recovery)
The reason for having a watchdog program as opposed to just rely on user queries to detect errors is that it can be done automatically. This is the preferred method because it allows for a proactive detection.
I've got a situation where i have one system running a master application that communicates with slave applets on other systems, problem is, i can't guarentee that the slave applets will be running, nor that an operator can physically utilize the system to start the applet (and I'm also assuming they don't know how to use Remote desktop, these are minimum wage test operators)
Is there an easy way to remotely launch an executeable on another system?
security is not a concern here as this is a closed network.
If you're on the same network and have access credentials (username+password) to the remote computer, then Mark Russinovich's PsExec is just the tool you need.
WMI is your friend. See the following article which covers starting processes locally and remotely using WMI:
How To: (Almost) Everything In WMI via C# Part 2: Processes (CodeProject)
Kev
You can use the Windows AT command to schedule tasks on a remote machine.
Any chance of converting the remote applets into Windows services? They can be configured to start when the system starts; to retry if they fail; and to notify someone if there are problems. They're quite trivial to create with Visual Studio.
here's a 2 step solution
Write a batch file to kick start
the application/service in the
context
Have the batch file on a
shared network path which can be
accessed from the machine would like
to launch the application/service.
Honestly, I would suggest the PsExec solution by Piskvor. But you can try out this as well ;)
another simple solution if you're not on the same network (accessing your home computer to run teamviewer for example) is to create a rule in Outlook (if you have it) whereas if you receive an email say from yourself, you can have it start an application if there are certain pieces of text in the message body or subject line, for example:
Create a mailbox rule:
Step 1 - Conditions: From & With specific words in the body (from being your mail address and the message body: Start Teamviewer
Step 2 - Start Application (browse to the location of the .exe you want to launch)
Step 3 - enable that bad boy!
Obviously, you have to have Outlook open and accepting incoming mail in order for this to work.
you can tailor this to your requirements, ie: if Start Teamviewer is too easy, you can put codes or passwords in there too, so when the email arrives, it'll read the message, recognise the info based on the rule, and launch the application. :)