I like to control a third-party application from my application via dbus.
However, the third-party application has some parameters that cannot be controlled by it's dbus interfaces but must be set by command line at service activation.
How can I pass those arguments to the service by time of the activation?
If they are static, put them in the Exec= line of the D-Bus .service file for that service.
If they need to be dynamic, it is not possible. If so, I suggest you file a bug against the service you are trying to start, requesting that they expose those options over D-Bus.
Related
I am building something on Linux that includes syslog.h but I want to override the define for _PATH_LOG which currently points to /dev/log
I want the syslog API for this program only to point to a different socket and never send to /dev/log due to some unreasonable constraints imposed by Systemd. How can I override this define for this build alone? The define is nested in syslog-path.h which is included by syslog.h, so my program indirectly includes the header which defines this variable.
If you include syslog.h, you are using your machine's system logger (for example, syslogd).
By design, apps generate syslogs, and the system logging server decides where the logs go. If you want to use the system logger and have your app's logs go to a custom endpoint, you will need to modify your system logging server's configuration. You cannot specify a custom endpoint in code from within your app.
If you want to send syslogs directly from your app to a remote syslog server (bypassing the system logger), you can do that by using a third-party syslog client library.
Say I have a running volttron agent with a #RPC decorated method (if that's relevant). Are there any ways to call that method from outside of the volttron platform? (In my case from a django web server)
An agent may register endpoints on the VOLTTRON web service. A callback may be setup for the endpoint as needed.
The web service must be enabled and the agent needs to pass "enable_web=True" to the base agent constructor.
You can find the documentation and examples here: http://volttron.readthedocs.io/en/develop/specifications/webframework.html
Along with what kyle-monson mentions, you also have to run Volttron using the bind argument. This will expose the registered endpoints on the bind arg given.
e.g `volttron -vv --bind-web-address "https://127.0.0.1:7080"
OR specify the bind-web-address in the ~/.volttron/config
[volttron]
message-bus = rmq
bind-web-address = https://127.0.0.1:7080
Then you can send HTTP POST request to https://127.0.0.1:7080/rpc-method-name
rpc-method-name in the request URL being the registered method using self.vip.web.register_endpoint("/rpc-method-name", self.call_back_method_for_endpoint)
The call back method takes in two parameters "env" and "data"
For more details on this two parameters check the docs here
Is it necessary to use urlfetch under AppEngine? I'd like to write a generic client to use with one of my services, but, if urlfetch is required from AppEngine, how can I write a generic client for use both from outside AppEngine (for the public) and inside AppEngine (for my other services) without having to write two different versions or passing some kind of factory that produces the right implementation?
The application should pass an http.Client to your generic client. It can either be a parameter to the function or passed through a context as done in the oauth2 package.
If the application does not provide a http.Client through one of these mechanisms (nil arg or no value in context), then use the default client.
the title is quite general but my doubt is specific.
I have doubt regarding where to write the service logic code (in service control handler or in ServiceMain),as in whatever the functionality the service would perform . Is it in ServiceMain ?
I have looked upon these topics on MSDN relate to service. But ,didn't help me
http://msdn.microsoft.com/en-us/library/ms687414%28VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms685984%28v=vs.85%29.aspx
Basically, I want to start a socket listening on windows using a service. This listening socket logic code will be in service file because of I am going to use winexe utility to send this service from linux box to windows box. currently, winexe sends the winexesvc service file on windows. So, ultimately I am going to replace the existing winexesvc service so that it will perform listening on a particular port function when sent on windows. (Service skeleton would remain same but its task performing logic will change,right?). please tell if I am missing anything.
Thanks in advance.
Service control handler should only, well, handle control messages that are sent to the service (the ones shown in the examples you linked are SERVICE_CONTROL_STOP and SERVICE_CONTROL_INTERROGATE). These control messages are sent to the service from the environment.
The logic of your service should be implemented in the ServiceMain function, when all required initialization is done. In the example at the URL in your post, the service logic code is put into the SvcInit function (which is probably not the most appropriate name for a function that implements logic of a service).
I'm not sure if I'm on the right lines but this is what I'm trying to do, I have a Silverlight application and a WCF service, the Silverlight app "subscribes" to the WCF service using PollingDuplex and the service can send data to any connected clients which works.
The service is marked with [ServiceContract(CallbackContract = typeof(IServiceCallback))] and it is single instanced
The problem is there is another service which should be able to call a standard method on this service to pass it data that will get distributed to the connected Silverlight clients, but because of the above settings it requires it to use callbacks (I can't change the other service).
Is there a way to have both types of operations, callback and standard in the same service if that makes sense?
Thanks for your time
Yes. It is possible. I guess CallbackContract parameter will not stop you from using your service as a regular request/response service (though I have not tried it).
But for the same contract, you may have to define two end points with different bindings, one with PollingDuplexHttpBinding and another one with basicHttpBinding (with silverlight this is the only other option).
You have to make sure that you are calling the right operation from the clients using duplex and basic http bindings.