Particular/servicecontrolasbs.monitoring.init and particular/servicecontrolasbs.audit.init docker images throwing License error while running

We are trying to containerize service control tooling. We have gone through the documentation mentioned here ServiceControl. We are able run particular/servicecontrolasbs.init successfully but facing license issues while running particular/servicecontrolasbs.audit.init and particular/servicecontrolasbs.monitoring.init images. Is anybody else facing the same issue? Any help would be appreciated :slight_smile:

Error Log
2020-10-29 17:03:08.3664|1|Info|LoggingConfiguration|Logging to C:\servicecontrol.monitoring\logfile.2020-10-29.txt with LogLevel 'Warn'

`2020-10-29 17:03:08.7100|1|Error|ServiceControl.Monitoring.SetupCommand|Cannot run setup with a trial license`

Docker run command
docker run --name servicecontrol.audit.init -e “ServiceControl.Audit/ConnectionString=[ASB ConnectionString]” -e ‘ServiceControl/LicenseText=[LicenseText]’ -v c:/data/:c:/data/ -d particular/servicecontrolasbs.audit.init

Docker Container Details

Hi Nitin,

The keys for the environment variables are different for each of them.

To specify your licenses across environments you need to add the following keys:

  • ServiceControl/LicenseText
  • ServiceControl.Audit/LicenseText
  • Monitoring/LicenseText

The mismatch is due to the history of how these tools were developed in isolation, but they will be aligned eventually.

@WilliamBZA Thanks for the reply. License issue got resolved :partying_face: Now getting below error while running particular/servicecontrolasbs.audit.init image.

docker run --name servicecontrol.audit.init -e "ServiceControl.Audit/ConnectionString=[ConnectionString]" -e 'ServiceControl.Audit/LicenseText=[LicenseText]' -v c:/data/:c:/data/ -d particular/servicecontrolasbs.audit.init

2020-10-29 23:17:53.2938|1|Info|ServiceControl.Audit.Infrastructure.Settings.Settings|No settings found for audit log queue to import, default name will be used
2020-10-29 23:17:53.5750|1|Error|ServiceControl.Audit.Infrastructure.SetupBootstrapper|

Audit Infra not created

Is there any more information in the docker logs? The error seems incomplete. You should also be able to map the logs folder to a local volume to extract the log files

-v c:/logs:/c:/logs

@WilliamBZA Unfortunately there is no detailed error message and the same logged in the file. :slightly_frowning_face:

When I tried to debug code locally, found that the application is looking for ServiceControl.Transports.ASBS.dll under bin\Release\net462\ which is missing.

Exception on local machine
'Configuration of transport Failed. Ensure the assembly 'C:\Users\gqn7867\source\repos\ServiceControl\src\ServiceControl.Audit\bin\Debug\net462\ServiceControl.Transports.ASBS.dll' is present and that type is correctly defined in settings'

Later, I added the project reference of ServiceControl.Transports.ASBS then it started working. see below

However, when I compared infra with one of our existing service control infra found that particular.servicecontrol.audit queue is missing.


Do I need to do any other steps run particular/servicecontrolasbs.audit.init as I see ServiceControl.Transports.ASBS.dll is missing?

How did you build the dockerfile?

Did you do a release compile of the ServiceControl solution beforehand? Or did you use the builddockerimages.ps1 script?

@WilliamBZA Yes. Solution build was successful and created Docker images with builddockerimages.ps1 .

@WilliamBZA Any update on this? Let me know if needed I can raise a support ticket. :slight_smile:

Hi Nitin,

I can’t reproduce the project reference part you are describing, but I have found a bug with the startup code which would explain the error with no message.

I’ll ping you as soon as the fix is merged to master and you can re-pull and build the images again.

As for the particular.servicecontrol.audit queue, that’s expected. The particular.servicecontrol.audit endpoint has been changed to a SendOnly endpoint so no longer creates it’s own incoming queue.

1 Like


The fix has been merged to master. You should be able to pull and re-run the ./builddockerimages.ps1 script and have the correct startup behaviour for the init container now.

1 Like

Thanks, @WilliamBZA for the fix. I’m able to run the tooling locally :partying_face:

Running docker containers

Infrastructure created

Now, I’m trying to connect ServicePulse with containerized service control but facing connectivity issues. Do you how to connect with ServicePulse and ServiceInsight? Also, is it possible to host them in a docker container as well? Your help will be highly appreciated. :slight_smile:

You can inspect the docker images to find their IP Addresses and connect that way, or you can map the ports on the docker images to your local port.

E.g. docker run --name servicecontrol.audit.init -e "ServiceControl.Audit/ConnectionString=[ConnectionString]" -e 'ServiceControl.Audit/LicenseText=[LicenseText]' -v c:/data/:c:/data/ -p 33333:33333 -d particular/servicecontrolasbs.audit.init

More docker networking details here:

@WilliamBZA Thanks again for helping me with this :slight_smile:.
Now, I’m able to connect to Service Pulse and Service Insights when used the IP Address of the container.

Service Pulse Connection Succeded

Able to receive heartbeats of active endpoints

Service Insights Connection Succeeded but doesn’t load messages

2020-11-03 20:05:38.1230|45|Warn|ServiceControl.CompositeViews.Messages.ScatterGatherApi2[[ServiceControl.Monitoring.EndpointInstanceMonitoring, ServiceControl, Version=, Culture=neutral, PublicKeyToken=null],[System.Collections.Generic.IList1[[ServiceControl.Monitoring.KnownEndpointsView, ServiceControl, Version=, Culture=neutral, PublicKeyToken=null]], mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089]]|Failed to query remote instance at

System.Net.Http.HttpRequestException: An error occurred while sending the request. —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

at System.Net.Sockets.Socket.InternalEndConnect(IAsyncResult asyncResult)

at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)

at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)

— End of inner exception stack trace —

at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)

at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)

— End of inner exception stack trace —

at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

at ServiceControl.CompositeViews.Messages.ScatterGatherApi`2.d__17.MoveNext()

2020-11-03 20:05:53.2576|42|Info|ServiceControl.Recoverability.RetryProcessor|No batch found to forward.

2020-11-03 20:05:53.2576|38|Info|ServiceControl.Recoverability.RetryProcessor|No batch found to stage.

Am I missing something here? Also, Can we containerize Service Pulse as well?

Are you sure the IP address that you are specifying for the audit instance is correct? It will change each time it restarts unless you specify it with the docker networking settings. Given the inherent dependency between the networked components, you may be better off exploring some of the deeper network connect parameters:

In essence: the audit instance needs to start first, and then the main instance must be configured to connect to the audit instance. The main instance must be able to perform tcp/ip http calls to the IP address specified by the ServiceControl/RemoteInstances parameter.