I believe this is still problematic:
/app/${activemq.data}/kahadb
I expect ${activemq.data} to be expanded to the actual value
> On Jun 22, 2021, at 3:37 PM, Fabrice Triboix <[email protected]>
> wrote:
>
> I think I didn't miss it, but for some reason it doesn't get attached. So
> here is a copy/paste:
>
> FROM openjdk:11-jre
>
> # Environment variables: version and tarball stuff
> ENV ACTIVEMQ_VERSION 5.16.2
> ENV ACTIVEMQ apache-activemq-$ACTIVEMQ_VERSION
> ENV ACTIVEMQ apache-activemq-$ACTIVEMQ_VERSION
> ENV ACTIVEMQ_SHA512
> 27bb26786640f74dcf404db884bedffc0af4bfb2a0248c398044ac9a13e19ff097c590b79eb1404e0b04d17a8f85a8f7de87186a96744e19162d70b3c7a9bdde
>
> # Environment variables: ActiveMQ directories
> ENV ACTIVEMQ_HOME /app/activemq
> ENV ACTIVEMQ_BASE $ACTIVEMQ_HOME
> ENV ACTIVEMQ_CONF /app/conf
> ENV ACTIVEMQ_DATA /app/data
> ENV ACTIVEMQ_TMP /app/tmp
>
> # Environment variables: system stuff
> ENV DEBIAN_FRONTEND noninteractive
>
> WORKDIR /app
>
> RUN curl -fsSLo activemq.tgz
> "https://archive.apache.org/dist/activemq/5.16.2/apache-activemq-5.16.2-bin.tar.gz";
> \
> && checksum=$(sha512sum activemq.tgz | awk '{ print $1 }') \
> && if [ $checksum != $ACTIVEMQ_SHA512 ]; then \
> echo "Unexpected SHA512 checksum; possible
> man-in-the-middle-attack"; \
> exit 1; \
> fi \
> && tar xf activemq.tgz \
> && rm activemq.tgz \
> && ln -s "/app/$ACTIVEMQ" /app/activemq \
> && cd activemq \
> && rm bin/activemq-diag bin/env bin/wrapper.jar LICENSE NOTICE
> README.txt \
> activemq-all-5.16.2.jar conf/*.ts conf/*.ks \
> && rm -r bin/linux-x86-32 bin/linux-x86-64 bin/macosx \
> data docs examples webapps-demo \
> && useradd --system --no-create-home --home-dir /app/home activemq \
> && mkdir -p /app/home "$ACTIVEMQ_CONF" "$ACTIVEMQ_DATA"
> "$ACTIVEMQ_TMP" \
> && chown -R activemq:activemq "$ACTIVEMQ_CONF" "$ACTIVEMQ_DATA"
> "$ACTIVEMQ_TMP"
>
> USER activemq
>
> CMD ["/app/activemq/bin/activemq", "console"]
>
> ________________________________
> From: Fabrice Triboix <[email protected]>
> Sent: 22 June 2021 21:04
> To: [email protected] <[email protected]>
> Subject: Re: Roundup of the configuration files
>
>
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> It looks like I missed the Dockerfile, sorry about that. Here it is!
>
> ________________________________
> From: Fabrice Triboix <[email protected]>
> Sent: 22 June 2021 20:27
> To: [email protected] <[email protected]>
> Subject: Re: Roundup of the configuration files
>
>
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> Hi Matt,
>
> Please find attached my Dockerfile and docker-compose file. Also included is
> the "conf" directory I am mounting inside the container to configure
> ActiveMQ. Hopefully you should be able to reproduce the problem.
>
> Here is the full log when I run docker-compose up😒
>
> $ docker-compose up
> Creating network "ark_activemq_default" with the default driver
> Creating ark_activemq_activemq_1 ... done
> Attaching to ark_activemq_activemq_1
> activemq_1 | INFO: Using default configuration
> activemq_1 | Configurations are loaded in the following order:
> /etc/default/activemq /app/home/.activemqrc /app/activemq/bin/env
> activemq_1 |
> activemq_1 | INFO: Using java '/usr/local/openjdk-11/bin/java'
> activemq_1 | INFO: Starting in foreground, this is just for debugging
> purposes (stop process by pressing CTRL+C)
> activemq_1 | INFO: Creating pidfile /app/data/activemq.pid
> activemq_1 | Java Runtime: Oracle Corporation 11.0.11 /usr/local/openjdk-11
> activemq_1 | Heap sizes: current=260096k free=258119k max=4098048k
> activemq_1 | JVM args:
> -Djava.util.logging.config.file=logging.properties
> -Djava.security.auth.login.config=/app/conf/login.config
> -Djava.awt.headless=true -Djava.io.tmpdir=/app/tmp
> --add-reads=java.xml=java.logging
> --add-opens=java.base/java.security=ALL-UNNAMED
> --add-opens=java.base/java.net=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.util=ALL-UNNAMED
> --add-opens=java.naming/javax.naming.spi=ALL-UNNAMED
> --add-opens=java.rmi/sun.rmi.transport.tcp=ALL-UNNAMED
> --add-opens=java.base/java.util.concurrent=ALL-UNNAMED
> --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED
> --add-exports=java.base/sun.net.www.protocol.http=ALL-UNNAMED
> --add-exports=java.base/sun.net.www.protocol.https=ALL-UNNAMED
> --add-exports=java.base/sun.net.www.protocol.jar=ALL-UNNAMED
> --add-exports=jdk.xml.dom/org.w3c.dom.html=ALL-UNNAMED
> --add-exports=jdk.naming.rmi/com.sun.jndi.url.rmi=ALL-UNNAMED
> -Dactivemq.classpath=/app/conf:/app/activemq/../lib/:
> -Dactivemq.home=/app/activemq -Dactivemq.base=/app/activemq
> -Dactivemq.conf=/app/conf -Dactivemq.data=/app/data
> activemq_1 | Extensions classpath:
> activemq_1 |
> [/app/activemq/lib,/app/activemq/lib/camel,/app/activemq/lib/optional,/app/activemq/lib/web,/app/activemq/lib/extra]
> activemq_1 | ACTIVEMQ_HOME: /app/activemq
> activemq_1 | ACTIVEMQ_BASE: /app/activemq
> activemq_1 | ACTIVEMQ_CONF: /app/conf
> activemq_1 | ACTIVEMQ_DATA: /app/data
> activemq_1 | Loading message broker from: xbean:activemq.xml
> activemq_1 | INFO | Refreshing
> org.apache.activemq.xbean.XBeanBrokerFactory$1@8646db9: startup date [Tue Jun
> 22 19:25:11 UTC 2021]; root of context hierarchy
> activemq_1 | INFO | Using Persistence Adapter:
> KahaDBPersistenceAdapter[/app/${activemq.data}/kahadb]
> activemq_1 | INFO | Database ${activemq.data}/kahadb/lock is locked by
> another server. This broker is now in slave mode waiting a lock to be acquired
>
> After that, nothing gets logged any more.
>
> Thanks a lot for your help!
>
> Fabrice
>
> ________________________________
> From: Matt Pavlovich <[email protected]>
> Sent: 22 June 2021 18:23
> To: [email protected] <[email protected]>
> Subject: Re: Roundup of the configuration files
>
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> Flying blind here.. without more detailed logs or information there isn’t
> enough information to point to a root cause.
>
> I can confirm that people have run ActiveMQ in Docker containers for years,
> so I do not suspect you are running into a bug at this point.
>
> I’d look into this line next-- "${activemq.data}/kahadb/lock”. I would
> expect the log line to expand the value of vs output the literal macro
> expression “${activemq.data}”.
>
> -Matt Pavlovich
>
>> On Jun 22, 2021, at 11:46 AM, Fabrice Triboix <[email protected]>
>> wrote:
>>
>> Hi Matt,
>>
>> No, I am not using a volume at the moment.
>>
>> The data directory that I am using is /app/data and is owned by the
>> activemq user and activemq group with 755 permissions. ActiveMQ runs as
>> the activemq user. ActiveMQ clearly can create files there:
>>
>> activemq@7a5313d69a74:/app/data$ ls -al
>> total 20
>> drwxr-xr-x 1 activemq activemq 4096 Jun 22 16:44 .
>> drwxr-xr-x 1 root root 4096 Jun 22 16:38 ..
>> -rw-r--r-- 1 activemq activemq 610 Jun 22 16:44 activemq.log
>> -rw-r--r-- 1 activemq activemq 2 Jun 22 16:44 activemq.pid
>> -rw-r--r-- 1 activemq activemq 0 Jun 22 16:44 audit.log
>>
>> Cheers,
>>
>> Fabrice
>>
>>
>> ________________________________
>> From: Matt Pavlovich <[email protected]>
>> Sent: 22 June 2021 16:54
>> To: [email protected] <[email protected]>
>> Subject: Re: Roundup of the configuration files
>>
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you recognize the sender and know the
>> content is safe.
>>
>>
>> Are you using a volume? Could be permissions related that ActiveMQ is unable
>> to get a lock on the filesystem.
>>
>>> On Jun 22, 2021, at 8:57 AM, Fabrice Triboix <[email protected]>
>>> wrote:
>>>
>>> Hi Matt,
>>>
>>> I am running ActiveMQ as a Docker container, so I am positively certain
>>> that (1) there are no other ActiveMQ processes and (2) the "data" directory
>>> is empty at startup. Additionally, when I add back all the other
>>> configuration files (i.e. the files in the conf directory of the official
>>> tarball), this problem goes away.
>>>
>>> Cheers,
>>>
>>> Fabrice
>
