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

Closed
ianmjones opened this Issue Sep 26, 2016 · 2 comments

Projects

None yet

1 participant

@ianmjones
Member

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 ianmjones added the bug label Sep 26, 2016
@ianmjones ianmjones self-assigned this Sep 26, 2016
@ianmjones ianmjones changed the title from First run of container always exits with status 135. to First run of container always exits with status 135 on Mac OS X 10.11.6 (El Capitan) Sep 28, 2016
@ianmjones
Member
ianmjones commented Sep 28, 2016 edited

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 ianmjones changed the title from First run of container always exits with status 135 on Mac OS X 10.11.6 (El Capitan) to First run of container always exits with status 135 when local data volume resides within Dropbox folder hierarchy Sep 28, 2016
@ianmjones
Member

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!

@ianmjones ianmjones closed this Sep 28, 2016
@ianmjones ianmjones changed the title from First run of container always exits with status 135 when local data volume resides within Dropbox folder hierarchy to [RESOLVED] First run of container always exits with status 135 when local data volume resides within Dropbox folder hierarchy Sep 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment