This can also be done via an elevated command prompt using the sc
command. The syntax is:
sc config [service name] depend= <Dependencies(separated by / (forward slash))>
Note: There is a space after the equals sign, and there is not one before it.
Warning: depend=
parameter will overwrite existing dependencies list, not append. So for example, if ServiceA already depends on ServiceB and ServiceC, if you run depend= ServiceD
, ServiceA will now depend only on ServiceD. (Thanks Matt!)
Examples
Dependency on one other service:
sc config ServiceA depend= ServiceB
Above means that ServiceA will not start until ServiceB has started. If you stop ServiceB, ServiceA will stop automatically.
Dependency on multiple other services:
sc config ServiceA depend= ServiceB/ServiceC/ServiceD/"Service Name With Spaces"
Above means that ServiceA will not start until ServiceB, ServiceC, and ServiceD have all started. If you stop any of ServiceB, ServiceC, or ServiceD, ServiceA will stop automatically.
To remove all dependencies:
sc config ServiceA depend= /
To list current dependencies:
sc qc ServiceA
For future reference I have solved the issue, with some help from the RabbitMq community which pointed me in this direction, by a simple statement.
This suggests Erlang VM cannot create a thread. Do you have any resource or security restrictions in place?
This was directly in response to 2 items.
Failed to create aux thread
Not sure why it didn't occur to me before, because I did see this in the erlang dump
processes: 13064032
processes_used: 13064032
However I am not sure how the number of erlang processes convert to system process, but regardless I thought it was a bug or programming incompatibility. It just didn't make a whole lot of sense because the installation went smoothly on my virtual development server. As well as our old CentOs 5.1 server. Also as this was a new, sever with > 3x the speed of our old one, I thought hitting resources limits was not an issue. I just needed someone to say it to make it click
in my mind.
Anyway, after some researching I ran this command
#su rabbitmq
bash-4.1$ ulimit -a
=============================
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 128218
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) 131072
open files (-n) 4096
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 100
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
The important thing here is this part:
max user processes (-u) 100
Checking my development box ( which has a functional RabbitMq installation with the management plugin ) I further saw this.
Erlang processes 206
So it doesn't really take a genius to figure out that 206
is more then 100
so after some more research I discovered the default value for this setting is typically 1024, and that i can change it in /etc/security/limits.conf
In that file I found
* hard nproc 100
So I just upped that to the 1024
amount for the rabbitmq user
rabbitmq hard nproc 1024
And it fired right up! After starting it and checking the status, I see this
{processes,[{limit,1048576},{used,147}]},
I believe the limit here is system wide? Still not really sure how the erlang process and these other process numbers relate.
So in conclusion 100 process is not enough for erlang to work. This is a cloud hosted SSAE 16 dedicated webserver, typically the hosting company sets these up for use for resellers
, ie. you can farm out parts of the server to host you're clients websites. This is most likely why they set a default limit so low. We use this type of server because we do a lot of database querying and report writing, and it offers a fair amount of power for what we pay. So while the hardware meets our needs, the configuration doesn't fit our use case as well.
Hopefully this can help someone in the future.
Best Answer
If you reinstall RabbitMQ and have issues running it as a windows service, a workaround could be the following:
In cmd.exe, run from the rabbit sbin folder:
It worked for me on windows 7.