Right now I have a Java application running WMI querying event logs, this is painfully slow due to the nature of WMI (ok, not painfully, but it may not be able to keep up with our domain controller), and dllhost.exe gets hammered serving up WMI requests and remote DCOM objects, pretty unnecessary just to read logs.
The next bit of exploration is in Windows RPC calls, but I'm confused... is the Windows RPC implementation (sorta kinda not wonderfully documented for event logs) just another name for WMI? Or will I be receiving raw event log information?
Other than these two methods, does anyone know of any other ways to hook into the event log creation event so I can have the servers automatically push their logs to me? It would be nice if it was something that could be fairly easily implemented in Linux, but I can tamper with WINE and Mono if I have to...
Or would it probably be best to write and deploy scripts on all the servers and have them push it to my program on the Linux box (though now I have to worry about the uptime of all those scripts)?
Or better yet... should I just write a Java service that can plug into the event logs natively and install those on the various windows machines and have it hand off the logs to my central Linux box that way?
Jarapac looks promoising, I'm going to dig a little bit at this and see if Windows RPC performance is up to par and how hard it is to implement. If it's fairly straight forward: Yay! Windows RPC on Linux.
If not, it's simply not possible without your own implementation. :(
Related
We have a service running on a Windows Server 2003 machine. This service watches a particular folder on an FTP server, and when files appear there, it invokes one of a few different executables to process them.
I've been asked to find a way for staff to be alerted in some way when this service hangs or stops.
Can anyone suggest anything with just this much information? If not, what else would you need to know?
Seems we could write ANOTHER service to watch THIS service, but then there's a chance THAT one would stop ... so we haven't resolved anything.
About the only thing that I know if is writing another application or service that monitors if that service is running; something like that shouldn't have any unexpected behavior and stop, hopefully.
Another thing to do is go to the service in Windows, go to its properties, and then go to recovery options. From here, you can set the behavior of a service if it is to fail. The options in Windows 7 are to restart the service or computer, or run a program. This program could send some sort of notification. However, I don't know if any or all of these options exist in Server 2003. This would also not likely work if the service were to just hang, but a service watching it probably wouldn't either.
Also, if you have the source code, you can override some of the service-related methods such as OnStop() (for C#) to send a notification, but I don't believe this works with a failure.
My personal choice would be to set the recovery options just to restart the service on failure, unless it repeatedly fails, which there is also an option for. But just do what you think will work best for you; there isn't really a fail-safe method to do it.
UPDATE:
I did check, and Server 2003 does indeed have the same recovery options in the service manager. As the guys said above, you can deal with that, but it is only in C++ from what I have seen; there is also a command prompt way to do it:
sc failure [servicename] reset= 0 actions= restart/60000
I found that command here and you can look at it more in its MSDN documentation. You could call this command from C# or other languages if you are not using C++, or use it directly from the command prompt if you do not have the source code.
Use ChangeServiceConfig2() to define Failure Actions for your service. You could use that to invoke an external command to issue the alert (or do pretty much anything else you want) if the service terminates unexpectedly.
The SCM (the component which handles services) has built-in auto-restart logic that you can take advantage of to restart your service, as necessary. Additionally and/or alternatively, you can configure 'custom actions' to be associated with a failure of the service - the custom action can include launching a program of your own, which could then log the failure, and perhaps manually restart your service.
You can read more about such custom actions on MSDN by looking at the documentation of the structure used to configure such actions: SERVICE_FAILURE_ACTIONS. Once you fill that structure, you notify the SCM by calling the ChangeServiceConfig2 function.
Please don't ask "well, what happens if my failure handler program crashes" :)
I need to track to a log when a service or application in Windows is started, stopped, and whether it exits successfully or with an error code.
I understand that many services do not log their own start and stop times, or if they exit correctly, so it seems the way to go would have to be inserting a hook into the API that will catch when services/applications request a process space and relinquish it.
My question is what function do I need to hook in order to accomplish this, and is it even possible? I need it to work on Windows XP and 7, both 64-bit.
I think your best bet is to use a device driver. See PsSetCreateProcessNotifyRoutine.
Windows Vista has NotifyServiceStatusChange(), but only for single services. On earlier versions, it's not possible other than polling for changes or watching the event log.
If you're looking for a user-space solution, EnumProcesses() will return a current list. But it won't signal you with changes, you'd have to continually poll it and act on the differences.
If you're watching for a specific application or set of applications, consider assigning them to Job Objects, which are all about allowing you to place limits on processes and manage them externally. I think you could even associate Explorer with a job object, then all tasks launched by the user would be associated with your job object automatically. Something to look into, perhaps.
I've got a service that acts as a watchdog for several apps/servers. There are no user sessions on this machine. I'd like the watchdog to be capable of beeping on the internal speaker should something go wrong (that'd be my queue to go fix whatever it's complaining about)
when I try the Beep() API on Windows nothing happens - I suspect the problem is that the services session isnt permitted to make noises?
can I make this work? any other ideas for how to make the service alert me?
-CG
Call CreateFile on \device\beep, then send down IOCTL_BEEP_SET (see http://www.koders.com/c/fidFEC3527B9D951559D62722A9C0C603863106CA9B.aspx for details)
It may work if you allow it to interact with the desktop (an option configurable somewhere, I can't remember where).
But personally, I'd have it email me.
Though maybe you could have it use the task scheduling API to schedule a task for yourself, so next time you log on you can see it.
I don't know; you've got a few options. I'd avoid beeping though.
Try sending beep char "\a" to console. Not sure if it will work.
Beeping doesn't seem like a good idea - it might end up driving everyone mad....
I'd also agree about the "interact with desktop" option and you set this in the services parameters see A Windows Service without a template
I'd recommend creating a simple client application that polls that server to query for any problems and returns a set of status messages. Then an appropriate UI would be raised (e.g. balloon on the tray), an email sent, etc. containing any warning or failure messages.
This way you also know that the watchdog itself is running and has network connectivity - if the watchdog dies and/or machine locks up you wouldn't otherwise know.
It also avoids being thrown out of a window when the machine starts beeping continuously just after you go to lunch. [+1 to #mikej] :-)
The poll period should be around half (see Nyquist sampling rate) your minimum required response time.
Why not use the Windows scheduler?
I have several applications that have to run at certain times according to business rules not the typical every weekday at 1pm.
I also need a way for the applications to provide feedback of their progress so that I can have rules that notify me when the applications are running slow or aren't even running anymore.
What Windows API should I be looking into? (like, a time version of the FileWatcher apis)
What's the best way to have the application notify the scheduler of its progress (files, sockets, windows messages, ???)?
For Vista/Win2k8, there's the nice Task Scheduler 2.0 API: http://msdn.microsoft.com/en-us/library/aa384138(VS.85).aspx. Previous version have the Task Scheduler 1.0 API, but I've never used it.
AppControls has a CronJob component that you can use to create scheduled events. This saves your program from having to wake up every minute and check the schedule itself. Instead, just schedule the job and indicate a callback method.
I have used this component for scheduling jobs myself and have been very happy with the way that it works.
I think what you really want is a common framework for your applications that report to something (you or the system messages or tracing or perfmon, event log, whatever) and also to receive via some inter process protocol a way to receive messages and respond.
based on the reporting you can change the scheduling or make changes, etc.
So, there is some monitor app, and then each of your other apps does common reporting.
events I can think of:
- started
- stopped
- error
- normal log messages
- and of course specific things your apps do.
I think there are probably existing classes/framework that do this - you'll have to check around.
If it were me, I would make a service that could talk to all the other apps and perhaps was even an http server. It would be able to route messages to particular apps and start stop those processes and query them.
There are lots of ways to do what you want though. those were just off the top of my head.
Alternatively you might just be able to get these to be services and they handle messages sent to them. Their normal processing does nothing until they are "woken up" with some task command.
You have more questions in one. Normally you should split them. But let's overlook this and try to answer.
To schedule certain events (including running an application): Use TJvScheduledEvents from JVCL. IMHO JVCL is the best Delphi open source library around with extensive number of components, developers & support. TJvScheduledEvents is quite neat, uses threads for event scheduling and also you have in JVCL a detailed editor for your events (it needs a small hack to use it though).
To provide 'feedback' from your applications to a (remote) central point: A very very very good solution (if your requirements permit) is to log the progress of your applications in a table (let's call it LOG) on a Firebird server. In LOG you can have the following fields: COMPUTER, USERNAME, APPNAME, MSG, LOGDATE (etc. etc.). In the After Insert trigger of the LOG table you can fire an event (let's call it NEW_LOG). In your console app you can register the interest for this event and so, your application will be automatically updated with everything which happens in any of your applications, so you can do log analysis, graphs etc. Of course you can do it with IB, but IB costs.
...going on Windows API route you need headers (which probably aren't translated), you'll encounter our dearest Pointers/PChars etc. etc. Of course, building from scratch everything isn't worthwhile but when this is already done in a Delphi way, why don't use it?
Use service with a timer that is fired regulary (for example each minute). It reads the schedule and looks if some are due before the next iteration. If so, you can execute them.
You can add an interface that shows all running apps. For the feedback and query that using a desktop application.
We have an Oracle DB running on Linux.
When data is ready to report, a value is placed in a table in the DB.
Presently an app is scheduled to run every 10 seconds to check for the value and if it's there it prints out the report. NOT prety.
How can I make this pretty?
I sort of envision the Oracle DB somehow triggering the windows server to print (TCP/IP? Small service listening on windows box) so that the windows app only fires up when it's time to do work.
How would you get the Linux/Oracle system to "signal" the Windows box?
Actually, polling is quite a quick, cheap, resilient, and best of all - implemented method of achieving your goal.
Remote db-initiated triggers are wonderfully sexy, and it could be as simple as using Cups with Samba and printing directly from the Linux box. Or it could be as complicated as a full two-way RPC with error checking.
Either way, don't fix things that aren't broken.