I built an application that is running as a windows service and is installed through my code.
All is fine except at logon.
When at the first windows xp/2003 server logon screen, I am not sure if the service is running at all. If it is, then it does work as it's not functional (the service IS USING WINPCAP so that could be an issue).
The service settings are set to "interact with desktop" and run as SYSTEM.
How can I ensure the service will start before windows logon? Also how can I make sure it is running even after I log off?
There are a couple of issues to consider.
First, you can check if your service really is running before login and after logout by logging events to the Windows Event Log. Pretty much all services do this whenever they start and stop and yours should do the same.
It may be that WinPcap is part of the problem. There are a couple of golden rules for using WinPcap in a service.
1a) Your service must not do anything that might cause the WinPcap service to try to start up while your own service is starting up because this will cause a deadlock in the Windows Service Control Manager. That means that if the WinPcap service is not already SERVICE_RUNNING when your service begins startup, you must not do anything that might cause it to start until after your service is SERVICE_RUNNING.
There are two ways to ensure this. Either make your service dependent on npf, the Network Packet Filter service. Or do not call any WinPcap function until after your service is SERVICE_RUNNING. I've not tried this latter method. I presume then the WinPcap function will block until npf is SERVICE_RUNNING.
1b) If you make your service dependent on npf, you will also have to make it dependent on nm (Network Monitor Driver) - if and only if nm is installed on the system. nm provides WinPcap with PPP/VPN support, and WinPcap always tries to use it if installed. Obviously, if you make nm a dependency of your service and nm isn't installed then your service will fail to start.
I don't think there is a guaranteed way to ensure that your service starts up before the desktop appears. But you might be able to help things along by creating a Service Control Group, adding it to the end of the existing list of Service Control Groups, and putting your service into this group. I'm not entirely convinced that this is an 'approved' way to get your service to start sooner, because if there was an approved way then everyone would do it and it wouldn't work any more. But there is a suggestion that services in a group are started before services not in a group.
Look at HKEY_LOCAL_MACHINE, "SYSTEM\CurrentControlSet\Control\GroupOrderList" and HKEY_LOCAL_MACHINE, "SYSTEM\CurrentControlSet\Control\ServiceGroupOrder" and do a bit of Googling.
Related
I have Docker swarm full of containers. I need to monitor when something is up or down. I can do this in 2 ways:
attaching to the swarm and listen to events.
polling service list
The issue with events is that there might be huge traffic, plus if some event is not processed, we will simply loose information on whats going on.
For me it is not super important to get immediate results, but to have correct information on whats going on.
Any pros/cons from real-life project?
Listening to events- its immediate, but risky as if your event listening program crashes because of any reason, you will miss an important information and lead to wrong result. This Registrator program is based on events.
Polling- eventual consistent result. but if it solves your problem it is less painful way to grabbing the data. No matter if your program crashes or restart. We are using this approach for service discovery in our project and so far it served the purpose.
From my experience, checking if something is up or down should be done using a health check, and should be agnostic to the underlying architecture running your service (otherwise you will have to write a new health check every time you change platform). Of course - you might have services with specific needs that cannot be monitored that way - if this is the case you're welcome to comment on that.
If you are using Swarm for stateless services only, I suggest creating a health check route that can verify the service is healthy and even disconnect faulty containers from the service.
If you are running statefull stuff this might be trickier, but there are solutions for that too, usually using some kind of monitoring agent over your statefull container (We are using cloudwatch since we run on AWS, but there are many alternatives)
Hope this helps.
I was wondering if it is possible to offer Docker images, but not allow any access to the internals of the built containers. Basically, the user of the container images can use the services they provide, but can't dig into any of the code within the containers.
Call it a way to obfuscate the source code, but also offer a service (the software) to someone on the basis of the container, instead of offering the software itself. Something like "Container as a Service", but with the main advantage that the developer can use these container(s) for local development too, but with no access to the underlying code within the containers.
My first thinking is, the controller of the Docker instances controls everything down to root access. So no, it isn't possible. But, I am new to Docker and am not aware of all of its possibilities.
Is this idea in any way possible?
An obfuscation-based only solution would not be enough, as "Encrypted and secure docker containers" details.
You would need full control of the host your containers are running in order to prevent any "poking". And that is not the case in your scenario, where a developer does have access to the host (ie his/her local development machine) where said container would run.
What is done sometimes is to have some piece of "core" code to run on a remote location (remote server, usb device), in a way that the external piece of code on the one hand can do some client authentication but also and more importantly run some business core code in order to guarantee that the externally located code "has" to be executed to have the things done. If it were only some check that is not actually core code, a cracker could just override it and avoid calling it on the client side. But if the code is actually required to be run and its not then the software won't be able to finish its processing. Of course there is an overhead for all of this, both in complexity and probably computation times, but that's one way you could deploy something that will unfailingly be required to contact your server/external device.
Regards,
Eduardo
I have created a Datasnap service, using Bob Swart's white paper as a guide. I have been debugging and deployed succesfully using the VCL Forms application as a server. But when I try to deploy the service version, it installs ok, I then try to start the service and it immediately stops. The error in the event log would suggest that the port set is already in use, I have tried different port numbers for both the TCPServerTransport and the HTTPService without any joy. The DSServer is not set to Autostart as I want to set the Port number from a configuration file. The error message displayed in the event log is:
Service failed on start: Could not bind socket. Address and port are already in use..
I have also tried writing to a log file on start up and execute but it looks as if it is not getting this far.
Solution needed asap, before I have to revert back to a thick client which I do not really want to do.
Thanks
Firstly get a copy of TCPView from the Sysinternals suite (now run by Microsoft) and use it to monitor which app is using the port you want to use.
I would hazard a guess that if the app works fine as a stand alone (as you say it does) and you are trying to use the same port in the service then perhaps the service app is opening up the port at startup without you realizing it and then when you try to open the port manually the app finds it already in use. Or somehow the app is trying to open the port twice. The first time is successful but, maybe due to an event or an unexpected code path, the app tries to open it a second time and fails. TCPView will help spot this.
If you are sure that the port you have configured is actually free and not in use by any other software on the machine, then there might be some anti-virus / security software running that is blocking all software from listening on either specific ports or on any port except a few configured ones. The message you are getting could be one of the symptoms of how the anti-virus / security software handles attempts by apps to start listening on a port.
I am a seasoned Delphi developer and would like to create something like seamless terminal services where an application is executed on a server but appears on the the desktop of the client.
To someone working on the server I don't want them to see the remote application running (except if they looked in at the list of running processes).
I'm lost as to how to go about this, where to start, how to get an application to render to a surface other than the servers desktop.
Starting from 2008 Terminal Services (which has been rebranded to Remote Desktop Services) offers RemoteApps which do exactly what you describe. Citrix (XenApp) can do this on all windows (server) versions. So you might want to look at those products before deciding to recreate them yourself.
If you do decide to go on, this link might be interesting, it's a sample project called "Extending Microsoft's Terminal Services Client To Provide Seamless Windows"
From what you are describing, I'd say you should be looking at writing a windows service (not terminal services) and using a inter-process-communications (IPC) system to get status information to a "client" application that can be run by the appropriate user, either on the same machine or another over the network.
Myself, I do exactly this using the RemObjects SDK which makes my client application look like it is just making function calls, but actually they go to the server which implements them. The server can then get on with its job in one (or more) thread, and all the user interface is done in the client which finds out what to display using the IPC channel.
I'm using the UPS service to monitor the state of my UPS from an application -- the key at HKLM\SYSTEM\CCS\Services\UPS\Status has all the information you can get from the Power control panel. BUT -- I'd like to be able to tell the UPS to shut down from my app as well. I know that the service can tell the UPS to shut down -- for instance, after running a set number of minutes on battery -- and I'm wondering if there's some kind of command I can send to the service to initiate a shutdown manually.
I'm having trouble searching for this information -- people tend to misspell "Uninterruptible" (hrm, Firefox red-lined that but doesn't have an alternative) and "UPS" just gets hits for the shipping service. Maybe I can do something through System.ServiceController, or WMI?
CLARIFICATION: Yes, I am talking about powering down the physical UPS device. I know how to stop the service. I figured it would be a common problem -- I want my UPS to turn off with the PC. I had an idea I'm going to try, based on this page. You see, APC (and everybody else) has to supply a DLL for the UPS service to call, and since the function calls are well documented, there's no reason I shouldn't be able to P/Invoke them. I'll re-edit this once I know whether or not it worked.
Update: I tried invoking UPSInit, then UPSTurnOff, and nothing happens. I'll tinker with it some more, but the direct call to apcups.dll might be a dead end.
Check my comments to Herman, you want to shut the UPS down, not the UPS SERVICE, correct? I mean, you want that thing to shut off, kill the power, etc, right?
If so, you are looking it on a UPS by UPS model. I doubt two of them would work the same.
In your searches, instead of UPS, try "APC", or "battery". I think a lot of the code is what runs on laptops to deal with being on battery, etc...
Some place hidden in some dusty old files I have protocol information for APC UPS's, and the commands they respond to, and what they send to the PC etc. But this was WAY back in the day when we used to connect our UPS's to our computers with SERIAL cables... You could actually talk to a UPS with Qmodem or Hyperterm...
Learned it from talking to the guys at APC. They are very nice, and helpful. Now-a-days, I think you just post a URL coming from your Powerchute software, and it will talk directly to the UPS, and carry out your commands.
OK, I have the answer (tested!), but it's not pretty. My APC UPS communicates using the APC "Smart" protocol (more here). What you need in my case is a "soft shutdown", "S" command. But first you need to make sure it's in "Smart" mode ("Y"). Now, if you want to let the Windows UPS service monitor state, the service will have an iron grip on the COM port. So you can either a) let the Windows service turn the UPS off, or b) kill the service and turn the UPS off yourself.
The UPS itself has a "grace period" after it gets the "S" command, giving you time to shut down your OS. This means that to do (a) above, you have to:
Kill utility (mains) power
Wait for the Windows UPS Service timeout (default and minimum 2 minutes)
Wait for Windows to shut down -- right near the end, it will send the "S" command
Wait for the UPS grace period, after which it will actually turn itself off
I think we're going to opt for (a), just because (b) involves extra work killing the service and implementing the serial comms.
Please, tell in what language are you trying to do that... if you're using .NET you can do that with ServiceController class (read the docs).
For controlling services in Win32 API using C/C++, Service Functions (Windows).
For example to stop a service you can use ControlService function as follows (this is a quick and dirty example):
OpenService (hServMgr, TEXT("\\UPS_SERVICE_0"), SC_MANAGER_ALL_ACCESS);
SERVICE_STATUS stat;
ControlService (hUpsService, SERVICE_CONTROL_STOP, &stat)
Note that you need to provide a Service Manager handle in hServMgr and the \\UPS_SERVICE_0 name is the name that must match with your desired UPS service (either the Windows built-in or another).
Remember that to stop a service you need the proper security rights. This is not a problem with an Adminstration account, but keep in mind what happens when logging with a non-admin account.
Hope that helps.
About shutting down the physical UPS device, I remember back in WIn98 days I was able to poweroff the device talking with the UPS through the COM port, altough I don't remember the brand or how the programming interface was.