[RESOLVED] First run of container always exits with status 135 when local data volume resides within Dropbox folder hierarchy

[ianmjones]

When starting a container for the very first time, it always exits with status 135.

If you bring the container down and then up again, it'll be fine.

Creating network "actordbfordocker_default" with the default driver
Creating actordbfordocker_actordb-server-1_1
Creating actordbfordocker_actordb-server-3_1
Creating actordbfordocker_actordb-server-2_1
Ians-MBP:actordb-for-docker ian$ docker-compose ps
               Name                             Command               State     Ports 
-------------------------------------------------------------------------------------
actordbfordocker_actordb-server-1_1   dumb-init actordb foreground   Exit 135         
actordbfordocker_actordb-server-2_1   dumb-init actordb foreground   Exit 135         
actordbfordocker_actordb-server-3_1   dumb-init actordb foreground   Exit 135         
Ians-MBP:actordb-for-docker ian$ docker-compose logs
Attaching to actordbfordocker_actordb-server-2_1, actordbfordocker_actordb-server-3_1, actordbfordocker_actordb-server-1_1
actordb-server-2_1  | config is OK
actordb-server-2_1  | -config /etc/actordb/app.config -args_file /etc/actordb/vm.args -vm_args /etc/actordb/vm.args
actordb-server-2_1  | Exec:  /usr/lib/actordb/erts-7.2/bin/erlexec -boot /usr/lib/actordb/releases/0.10.22/actordb               -config /etc/actordb/app.config -args_file /etc/actordb/vm.args -vm_args /etc/actordb/vm.args              -pa /usr/lib/actordb/lib/actordb-patches -noshell -- foreground
actordb-server-2_1  | Root: /usr/lib/actordb
actordb-server-3_1  | config is OK
actordb-server-2_1  | [os_mon] memory supervisor port (memsup): Erlang has closed
actordb-server-3_1  | -config /etc/actordb/app.config -args_file /etc/actordb/vm.args -vm_args /etc/actordb/vm.args
actordb-server-2_1  | [os_mon] cpu supervisor port (cpu_sup): Erlang has closed
actordb-server-3_1  | Exec:  /usr/lib/actordb/erts-7.2/bin/erlexec -boot /usr/lib/actordb/releases/0.10.22/actordb               -config /etc/actordb/app.config -args_file /etc/actordb/vm.args -vm_args /etc/actordb/vm.args              -pa /usr/lib/actordb/lib/actordb-patches -noshell -- foreground
actordb-server-3_1  | Root: /usr/lib/actordb
actordb-server-3_1  | [os_mon] cpu supervisor port (cpu_sup): Erlang has closed
actordb-server-3_1  | [os_mon] memory supervisor port (memsup): Erlang has closed
actordb-server-1_1  | config is OK
actordb-server-1_1  | -config /etc/actordb/app.config -args_file /etc/actordb/vm.args -vm_args /etc/actordb/vm.args
actordb-server-1_1  | Exec:  /usr/lib/actordb/erts-7.2/bin/erlexec -boot /usr/lib/actordb/releases/0.10.22/actordb               -config /etc/actordb/app.config -args_file /etc/actordb/vm.args -vm_args /etc/actordb/vm.args              -pa /usr/lib/actordb/lib/actordb-patches -noshell -- foreground
actordb-server-1_1  | Root: /usr/lib/actordb
actordb-server-1_1  | [os_mon] memory supervisor port (memsup): Erlang has closed
actordb-server-1_1  | [os_mon] cpu supervisor port (cpu_sup): Erlang has closed

Nothing is written to the console.log, crash.log, error.log or sasl-error.log files.

[ianmjones]

Experiments on different versions of macOS and Linux didn't suffer from the "Exit 135" problem, so it looks like it might be an issue either with Docker on Mac OS X 10.11.6, or just my MacBook Pro.

[ianmjones]

Finally found the cause!

It seems to be that if you run the container with the /var/lib/actordb volume mounted somewhere within a Dropbox folder, it'll "Exit 135" when creating the lmdb and lmdb-lock files.

Not something my container or ActorDB can possibly ever address.

Just don't mount the container's /var/lib/actordb volume into a Dropbox folder, even during development!