<p>I am attempting to start a RabbitMQ image in my AKS cluster. The VMs comprising the cluster are on a private VNET and have firewall rules in place.</p>

<p>What needs to be allowed through the firewall isn't clear (or if it's even the problem).</p>

<p>Here's the output when the pod starts:</p>

<blockquote>
  <h1>BOOT FAILED</h1>
  
  <p>Config file generation failed: Failed to create dirty io scheduler
  thread 6, error = 11</p>
  
  <p>Crash dump is being written to:
  /var/log/rabbitmq/erl_crash.dump...Segmentation fault (core dumped)</p>
  
  <p>{"init terminating in do_boot",generate_config_file} init terminating
  in do_boot (generate_config_file)</p>
  
  <p>Crash dump is being written to:
  /var/log/rabbitmq/erl_crash.dump...done</p>
</blockquote>

<p>I have attached persistent volumes to /var/log and /var/lib/rabbitmq but there's no log files or anything else that aids in debugging this issue. Schema, lost+found, and other rabbitmq folders and files are created, so it's reading/writing fine.</p>

<p>Here's the YAML I'm using to create the pod:</p>

<pre><code>   apiVersion: extensions/v1beta1
   kind: Deployment
   metadata:
     name: mayan-broker
   spec:
     replicas: 1
     template:
      metadata:
       labels:
         app: mayan-broker
      spec:
        containers:                           
         - name: mayan-broker
           image: rabbitmq:3
           volumeMounts:
           - name: broker-storage
             mountPath: /var/lib/rabbitmq
           - name: broker-logging
             mountPath: /var/log/rabbitmq
           ports:
             - containerPort: 5672
           env:
               -  name: RABBITMQ_DEFAULT_USER
                  value: mayan
               -  name: RABBITMQ_DEFAULT_PASS
                  value: mayan
               -  name: RABBITMQ_DEFAULT_VHOST
                  value: mayan      
        volumes:
         - name: broker-storage
           persistentVolumeClaim:
             claimName: rabbit-claim    
         - name: broker-logging
           persistentVolumeClaim:
             claimName: logging-claim
</code></pre>

<p>YAML without volumes and mounts per request, yielding the same result:</p>

<pre><code>   apiVersion: extensions/v1beta1
   kind: Deployment
   metadata:
     name: mayan-broker
   spec:
     replicas: 1
     template:
      metadata:
       labels:
         app: mayan-broker
      spec:
        containers:                           
         - name: mayan-broker
           image: rabbitmq:3
           ports:
             - containerPort: 5672
           env:
               -  name: RABBITMQ_DEFAULT_USER
                  value: mayan
               -  name: RABBITMQ_DEFAULT_PASS
                  value: mayan
               -  name: RABBITMQ_DEFAULT_VHOST
                  value: MAYAN     
</code></pre>

wvisaacs
<p>I had the same problem with AKS (I'm starting to think it's an AKS thing).</p>

<p>Basically AKS limits the number of thread a pod can use, and rabbitmq (and everything Erlang in general) uses <em>a lot</em> of threads.</p>

<p>You can use env vars in your yaml to reduce the number of threads, like in my config:</p>

<pre><code>apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: rabbitmq
spec:
  serviceName: "rabbitmq"
  replicas: 1
  selector:
    matchLabels:
      app: rabbitmq
  template:
    metadata:
      labels:
        app: rabbitmq
    spec:
      containers:
      - name: rabbitmq
        image: rabbitmq:3.7-management
        env:
            # this needs to be there because AKS (as of 1.14.3)
            # limits the number of thread a pod can use
            - name: RABBITMQ_IO_THREAD_POOL_SIZE
              value: "30"
        ports:
        - containerPort: 5672
          name: amqp
        resources:
          limits:
            memory: 4Gi
          requests:
            cpu: "1"
            memory: 1Gi
</code></pre>

<p>I'm using a statefulsets, but the fix is the same for a deployment. </p>
