The services terminate due to MSMQ not being started at the time they're trying to start up, so the obvious solution would be to set the startup type to automatic (delayed). Rather than going with the obvious solution I'm wondering if there's something I'm doing wrong?
I'm using NServiceBus V5 on Win2012 and started to get these messages on all my installed services after I upgraded to V5 from V4. They're installed to start automatically when the server boots up. This hasn't happened before, and the services start normally if I manually start them.
I don't think you're doing anything wrong--I think it's what you suspect: your service is starting up before the Message Queuing Service is ready.
Assuming the NServicebus is running in NServiceBus.Host.exe, in order to get the service to start after MSMQ, there's a switch that needs to be used when installing the service (I used one line, broke it into multiple lines for readability):
.\NServiceBus.Host.exe /install
/servicename:"service"
/displayname:"display"
/dependsOn:"MSMQ"
I had tried "Message Queing" since that's what was in the service control manager, but I guess it doesn't take the display name. I found that MSMQ was the service name by right clicking on the service and viewing the service name field at the top.
You can set service dependencies without having to reinstall.
use the following command: sc config YOURSERVICENAME depend=MSMQ
Related
Can someone suggest a way out of this issue please?
Can't start IIS either through command prompt or through iis itself.
IISRESET in command prompt throws the below error:-
The service did not respond to the start or control request in a timely fashion. (2147943453, 8007041d)
I have IIS 6.2(Build 9200) and OS is Win 8.1 Enterprise
I have encountered this problem before for IIS6,7 and IIS10. I tried for a very long time but it was not solved by any method.
The definitive and permanent solution is IIS uninstall and reinstall. When IIS is removed, you also need to delete it in C:\Windows\System32\inetsrv folder.
I have a windows service programmed in vb.NET, using Topshelf as Service Host.
Once in a while the service doesn't start. On the event log, the SCM writes errors 7000 and 7009 (service did not respond in a timely fashion). I know this is a common issue, but I (think) I have tried everything with no result.
The service only relies in WMI, and has no time-consuming operations.
I read this question (Error 1053: the service did not respond to the start or control request in a timely fashion), but none of the answers worked for me.
I Tried:
Set topshelf's start timeout.
Request additional time in the first line of "OnStart" method.
Set a periodic timer wich request additional time to the SCM.
Remove TopShelf and make the service with the Visual Studio Service Template.
Move the initialization code and "OnStart" code to a new thread to return inmediately.
Build in RELEASE mode.
Set GeneratePublisherEvidence = false in the app.config file (per application).
Unchecked "Check for publisher’s certificate revocation" in the internet settings (per machine).
Deleted all Alternate Streams (in case some dll was marked as web and blocked).
Removed any "Debug code"
Increased Window's general service timeout to 120000ms.
Also:
The service doesn't try to communicate with the user's desktop in any way.
The UAC is disabled.
The Service Runs on LOCAL SYSTEM ACCOUNT.
I believe that the code of the service itself is not the problem because:
It has been on production for over two years.
Usually the service starts fine.
There is no exception logged in the Event Log.
The "On Error" options for the service dosn't get called (since the service doesn't actually fails, just doesn't respond to the SCM)
I've commented out almost everything on it, pursuing this error! ;-)
Any help is welcome since i'm completely out of ideas, and i've been strugling with this for over 15 days...
For me the 7009 error was produced by my NET core app because I was using this construct:
var builder = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile("appsettings.json");
and appsettings.json file obviously couldn't be found in C:\WINDOWS\system32.. anyway, changing it to Path.Combine(AppContext.BaseDirectory, "appsettings.json") solved the issue.
More general help - for Topshelf you can add custom exception handling where I finally found some meaningfull error info, unlike event viewer:
HostFactory.Run(x => {
...
x.OnException(e =>
{
using (var fs = new StreamWriter(#"C:\log.txt"))
{
fs.WriteLine(e.ToString());
}
});
});
I've hit the 7000 and 7009 issue, which fails straight away (even though the error message says A timeout was reached (30000 milliseconds)) because of misconfiguration between TopShelf and what the service gets installed as.
The bottom line - what you pass in HostConfigurator.SetServiceName(name) needs to match exactly the SERVICE_NAME of the Windows service which gets installed.
If they don't match it'll fail straight away and you get the two event log messages.
I had this start happening to a service after Windows Creator's Edition update installed. Basically it made the whole computer slower, which is what I think triggered the problem. Even one of the Windows services had a timeout issue.
What I learned online is that the constructor for the service needs to be fast, but OnStart has more leeway with the SCM. My service had a C# wrapper and it included an InitializeComponent() that was called in the constructor. I moved that call to OnStart and the problem went away.
Mule is running as a Windows Service, and when the server is restarted we need the flows to start back up in a very specific manner.
I have edited the bat file located in $HOME\bin\mule.bat
with these parameters:
./mule -app app1:app2:app3 start
However this does not appears to make a difference in the startup.
Here is the answer from Mule.
On Windows
Run as Windows Service:
Follow the next steps to control the order with a system variable.
Stop the windows service.
Create a system variable MULE_STARTUP_ORDER containing the desired order (apps separated by ":") i.e.:APP1:APP2:APP3
Add the next lines to the $MULE_HOME/conf/wrapper.conf file:
wrapper.app.parameter.10=-app
wrapper.app.parameter.11=%MULE_STARTUP_ORDER%
Start the windows service.
The order should be the expected.
Note: With this method you need to manually add/delete applications to the MULE_STARTUP_ORDER variable for them to start
It maybe of help to others running Mule 3.8 Standalone as a Window service, but this worked for me.
Remove the existing Mule service (if it exists) by running the following from the command line
${MULE_HOME}\bin>mule remove
Where ${MULE_HOME} is the directory where Mule is installed
Edit the following file
\Mule\bin\mule.bat
set MULE_OPTS=set.MULE_APP=%MULE_APP%
set.MULE_APP_LONG=%MULE_APP_LONG% set.MULE_HOME="%MULE_HOME%"
set.MULE_BASE="%MULE_BASE%" set.MULE_LIB=%MULE_LIB%
wrapper.working.dir=%_REALPATH% wrapper.app.parameter.1=-app
wrapper.app.parameter.2="appName1:appName2" wrapper.app.parameter.3=%3
wrapper.app.parameter.4=%4 wrapper.app.parameter.5=%5
wrapper.app.parameter.6=%6 wrapper.app.parameter.7=%7
wrapper.app.parameter.8=%8 wrapper.app.parameter.9=%9
Where appName1 and appName2 are the names of my Mule applications in \Mule\apps
Install Mule as a service again
${MULE_HOME}\bin>mule install
Start your Mule service and check the logs to confirm the Mule apps are starting in the order expected.
Finally, if you wished to do the same from the command line, then try
${MULE_HOME}\bin>mule -app=appName1:appName2
Hope that helps!
Where did you found out that would even work?
Have a look over here in the docs about starting/stopping Mule.
https://docs.mulesoft.com/mule-user-guide/v/3.7/starting-and-stopping-mule-esb
As far as i know that isn't possible.
You can change the initial state of your flows in Anypoint Studio to stopped.
That will help you out for the flows that you don't want to start after restart.
However you should start them afterwards manually via MMC or via the API.
I am using NServiceBus 5. My messages are sending / receiving correctly, but I'm having trouble with Service Pulse. I have configured the auditing using the default endpoint names.
When I navigate to Service Pulse (http://localhost:9090/) I get the following error.
Can't connect to ServiceControl (http://localhost:33333/api/)
Looking at my services I see that Particular ServiceControl is not started. When I attempt to start it, it starts and immediately stops.
I have checked the logs at:
%LOCALAPPDATA%\Particular\ServiceControl\logs
and
%WINDIR%\System32\config\systemprofile\AppData\Local\Particular\ServiceControl\logs
But apart from the errors about the missing queues from yesterday (see below) - nothing. When I attempt to restart the service now I get no errors.
Anyone know what I should do to get Service Pulse working correctly?
I deleted all my private queues yesterday thinking that they would be recreated automatically. Now I realise only the endpoint ones are recreated, I have recreated some manually.
Right now along with my endpoint queues I have:
audit
auditqueue
error
error.log
particular.servicecontrol
particular.servicecontrol.errors
particular.servicecontrol.retries
particular.servicecontrol.timeouts
particular.servicecontrol.timeoutsdispatcher
--- EDIT ---
Ended up just uninstalling and reinstalling - fixed the problem.
ServiceControl --uninstall
ServiceControl --install
Try and run ServiceControl --install in an admin Console and it will create the queues (C:\Program Files (x86)\Particular Software\ServiceControl> .\ServiceControl.exe --install)
If not you need to add these queues manually or reinstall ServiceControl:
particular.servicecontrol
particular.servicecontrol.errors
particular.servicecontrol.timeouts
particular.servicecontrol.timeoutsdispatcher
to make long story as short as possible, I made a duplex WCF service, using wsdualhttpbinding, tested it on my local machine using Visual Stuido and using IIS7, thigs are working fine (i had to use windows authentication on IIS7 to make it work thu). Any way, I published the duplex service on my company network (LAN network, windows domain, IIS 6) which i used to for many WCF services (basic and ws http bindings and worked fine) and the problem is I can not get the service to work, I tried all possible configurations to the app.config and to the web.config files, still i can not make it work.. The problem is when the client start calling the duplex service It hangs and no error message or whatsoever, and after few minutes it gives me a timeout error.. there is no error at server side ( i have checked the even viewer). There is not error about port 80 or access privileges. Is there anything i am missing? anything i should take care of and i forgot? i have been awake for 20 hours trying to find a solution because i have a time line to follow or my boss will Dispose() Me..
i have tried the following:
1- I set the IsOneWay = true..
2- I run the program as admin.
3- I i set the base address to another port.. same result..
4- I used windows auth, none... same result..
5- i have tried another machine to test the client.. same result.. it hangs with no reponse.
6- I also tried running the client on windows vista, 7 and xp... same result..
7- I have played with all kind of configurations in config files and i made sure its the same on both files (app.config and web.config)..
8- I have added a static constructor in the service side to see if the service was ever reached by the client, i added few lines to add a value in the db.. and nothing was written to db.. so it was never reached..
9- Yes, when i access the service SVC page i see the page and it worked fine.. I could access the metadata as well..
10- restarting the server, restarting IIS server, Recycling AppPool...etc..
I tried all of that and many other solutions and tricks.. same result when the app is on IIS.. the strange thing is, there is no error at server side.. and i only get TimeOut error (if i get it).. While If i tried the service on the IIS installed locally it works fine.. change the config file to point to the company IIS server,,, no luck!
Is there anything i am missing??? could be something simple but i just missed it..