Archived

This forum has been archived. Please start a new discussion on GitHub.

Using Ice.Config with a Windows Service

Hello,

I have a windows service that I have installed using

myApp.exe --install MyApp --Ice.Config=/path/myApp.properties

Whenever I want to start the service, however, the --Ice.Config option is stripped out and my service has no idea where my Ice.Config is.

I know I can set an enviornment variable to point to the ice config file and that solves my problem for one service.

However, I when I have more than one ice service running they are going to look at the same config file which I do not want.

So, my question is, how do I wire into the service arguments the --Ice.Config=/path/myApp.properties for the startup of my Windows Service.

Comments

  • mes
    mes California
    Welcome to the forum.

    We require all members to add a signature as described in this post.

    Take care,
    - Mark
  • Okay, signature added as requested
  • mes
    mes California
    Thanks Frank.

    The first step is to make sure that the --Ice.Config argument is actually being passed to the service executable. Use the Services control panel and look at the properties for your service; you should see this argument in the Path to executable field.

    The Ice run time removes all Ice-related options from the argument vector passed to Ice::initialize, so your application would not normally see this argument unless you examine the argument vector before Ice gets its hands on it.

    Assuming that --Ice.Config is being passed to the executable but does not appear to have any effect, you should also check that the service has sufficient privileges to read the configuration file. However, normally the service wouldn't start successfully if it was unable to access the configuration file and there would be an error message in the event log.

    If you haven't already seen it, I wrote an article about Windows services in this issue of our newsletter that might be helpful.

    Take care,
    - Mark
  • Hi Mark,

    Yes, I am passing in the --Ice.Config=/path/MyApp.config whenever I do I do an install via --install.

    It finds it correctly and everything's good at this point. The problem is that it strips it away after it installs the service. If I go to my services window and look at the service it does not have the --Ice.Config hardwired into its argument.

    Now I have to either define the enviornment variable for it to work at this point or I have to start the service manually with the "one time only" argument where I can readd --Ice.Config=/path/MyApp.config.

    Optionally I can edit the registery setting and readd my --Ice.Config back to the service but I want to avoid that altogether.

    I would like to have the --Ice.Config variable hard wired into my service argument because I am going to have more than one ICE service running on the same box and want them to find their two seprate --Ice.Config's automatically upon bootup.

    So, to recapp,

    Whenver you do a

    MyApp.exe --install --Ice.Confg=/path/MyApp.config

    And then go to services under Windows the installed service has the --Ice.Config stripped from it. I don't want that part stripped. I want that service to be able to automatically start upon bootup with the --Ice.Config path hardwired into it's path. The reason I want it hardwired is because I am going to have more than one service.
  • mes
    mes California
    Hi,

    As an experiment, I ran the following command using Ice 3.1.0:

    > glacier2router --install Glacier2 --Ice.Config=C:/MyConfig

    In the Properties dialog for this service, the contents of Path to executable are shown below:

    C:\Ice-3.1.0\bin\glacier2router.exe --service Glacier2 --Ice.Config=C:/MyConfig

    So the --Ice.Config option is clearly not being stripped, at least for this service. If your service makes use of the Ice::Service class, which it appears to do, all of this should be handled for you. I'm afraid without a small, self-contained example that demonstrates this problem, it will be difficult for us to determine the cause.

    Take care,
    - Mark
  • Sample where I found the problem.

    Whenever you have

    Ice::PropertiesPtr properties = Ice::createProperties(argc, argv);

    in main it causes the Ice.Config to be stripped out.

    //Ice includes
    #include <Ice/Ice.h>
    #include <Ice/Service.h>
    
    //std includes
    #include <string>
    using namespace std;
    
    class ServerService : public Ice::Service 
    {
    
    	protected:
    		virtual bool start(int, char*[])
    		{
    			return true;
    		}
    
    	private:
    };
    
    
    int main(int argc, char* argv[])
    {
    	Ice::PropertiesPtr properties = Ice::createProperties(argc, argv);
    	ServerService svc;
    	return svc.main(argc, argv);
    }
    
    
  • mes
    mes California
    That's correct. The newly-created Properties object contains the properties defined in the configuration file, plus any Ice-related properties defined by other command-line options, and all of those options are removed from the argument vector. This would certainly explain why your service is not being configured properly.

    Is there a reason why you need to create a Properties object in main\?

    Take care,
    - Mark
  • bernard
    bernard Jupiter, FL
    When you create a Properties object with createProperties(argc, argv), you often use it later as a member of an Ice::InitializationData parameter passed to Ice::Application::main, Ice::Service::main, or Ice::initialize.

    Cheers,
    Bernard
  • I am creating it in main to be able to look at my arguments to see if the Ice.Config had been given or not.

    If Ice.Config is not given as an argument I give an error message indicating that Ice.Config has to be present. I can delay this error to the start method, however.