Open lukkamor opened 10 years ago
I see. It's probably because supervisor starts all the services at the same time, but CloudTunes needs a Mongod DB and a Redis connections upon boot. I will look into this over the weekend.
Thanks so much Jakub! Arturo
On Friday, September 12, 2014 1:51 PM, Jakub Roztočil notifications@github.com wrote:
I see. It's probably because supervisors starts all the services at the same time, but CloudTunes needs Mongod DB and Redis connections upon boot. I will look into this over the weekend. — Reply to this email directly or view it on GitHub.
Hi! I figured this out (I ended up making a bash container and looking at the error logs http://affy.blogspot.co.uk/2014/06/how-to-detach-from-running-docker-image.html :+1:)
So, if you dont have a local.py
file, you wont be able to start cloudtunes-server:
!!!Cannot import local settings!!!
You need to copy cloudtunes/settings/local.example.py
to cloudtunes/settings/local.py and fill in the None's.
https://github.com/jakubroztocil/cloudtunes#installation
So, I just added that file to the repo and the dockerfile worked fine.
I'm no docker expert, but I assume something like this would work:
ADD cloudtunes-server/cloudtunes/settings/local.example.py /home/cloudtunes-server/cloudtunes/settings/local.py
Actually, we should probably add instructions to the README.md to create the local.py file in that directory? As you'll need to configure your own personal keys in there...
Thanks Petems, I have added the local.py and still have the same problem. I think Jakub is looking at the way the components start and that might fix the problem.
@lukkamor You should patch supervisor.ini like following
From aeb50b20ff997055cf0b1cff56e9fc8294d55b4c Mon Sep 17 00:00:00 2001
From: kakawait <thibaud.lepretre@gmail.com>
Date: Mon, 22 Sep 2014 18:23:42 +0200
Subject: [PATCH] fix supervisor starting order
---
cloudtunes-server/production/supervisor.ini | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/cloudtunes-server/production/supervisor.ini b/cloudtunes-server/production/supervisor.ini
index aeafd09..b950ee6 100644
--- a/cloudtunes-server/production/supervisor.ini
+++ b/cloudtunes-server/production/supervisor.ini
@@ -11,6 +11,7 @@ autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/cloudtunes-server.log
loglevel=debug
+priority=998
;[program:cloudtunes-8001]
@@ -33,6 +34,7 @@ autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/cloudtunes-worker.log
loglevel=debug
+priority=999
[program:redis]
directory=/data
@@ -42,9 +44,11 @@ autorestart=true
user=root
stdout_logfile=/var/log/redis/stdout.log
stderr_logfile=/var/log/redis/stderr.log
+priority=2
[program:mongod]
command=/usr/bin/mongod --smallfiles
stdout_logfile=/var/log/supervisor/%(program_name)s.log
stderr_logfile=/var/log/supervisor/%(program_name)s.log
autorestart=true
+priority=1
--
1.8.4.2
It works for me.
upstream problem is following: https://github.com/Supervisor/supervisor/issues/122 but still open since 2012 :'(
Hi Jakub, thanks for the info. Still the same problem. I've just downloaded cloudtunes-master.zip, applied the patch to supervisor.ini, add the local.py file and still have the same problem. Maybe I am doing something wrong. I have the log file with all the building steps. Would that help? I am stuck. Thanks!
On Monday, September 22, 2014 12:26 PM, Thibaud Lepretre notifications@github.com wrote:
@lukkamor You should patch supervisor.ini like following From aeb50b20ff997055cf0b1cff56e9fc8294d55b4c Mon Sep 17 00:00:00 2001 From: kakawait thibaud.lepretre@gmail.com Date: Mon, 22 Sep 2014 18:23:42 +0200 Subject: [PATCH] test --- cloudtunes-server/production/supervisor.ini | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/cloudtunes-server/production/supervisor.ini b/cloudtunes-server/production/supervisor.ini index aeafd09..b950ee6 100644 --- a/cloudtunes-server/production/supervisor.ini +++ b/cloudtunes-server/production/supervisor.ini @@ -11,6 +11,7 @@ autorestart=true redirect_stderr=true stdout_logfile=/var/log/cloudtunes-server.log loglevel=debug +priority=998 ;[program:cloudtunes-8001] @@ -33,6 +34,7 @@ autorestart=true redirect_stderr=true stdout_logfile=/var/log/cloudtunes-worker.log loglevel=debug +priority=999 [program:redis] directory=/data @@ -42,9 +44,11 @@ autorestart=true user=root stdout_logfile=/var/log/redis/stdout.log stderr_logfile=/var/log/redis/stderr.log +priority=2 [program:mongod] command=/usr/bin/mongod --smallfiles stdout_logfile=/var/log/supervisor/%(program_name)s.log stderr_logfile=/var/log/supervisor/%(program_name)s.log autorestart=true
1.8.4.2 It works for me. upstream problem is following: Supervisor/supervisor#122 but still open since 2012 :'( — Reply to this email directly or view it on GitHub.
@lukkamor Yeah my bad my patch works "sometimes"... The only solution I found is to add the following directive inside [program:cloudtunes-8000]
and [program:cloudtunes-worker]
startretries=10
startsecs=10
The goal is to increase the number of retries before giving up. With 10 retries on my docker env it work, mongodb and redis had enough time to start. But you can tune it.
Tried: 20 retries and 30 seconds unsuccessfully. One thing I've noticed when building, I got all this errors: Step 12 : RUN gem install compass ---> Running in 4439341c025e Building native extensions. This could take a while... ESC[91mEnclosing class/module 'moduleFFI' for class FunctionType not known ESC[0mESC[91mEnclosing class/module 'moduleFFI' for class ArrayType not known ESC[0mESC[91mEnclosing class/module 'moduleFFI' for class Buffer not known ESC[0mESC[91mEnclosing class/module "BufferClass" for alias length total not known ESC[0mESC[91mEnclosing class/module 'rbffi_TypeClass' for class Mapped not known ESC[0mESC[91mEnclosing class/module 'moduleFFI' for module Platform not known ESC[0mESC[91mEnclosing class/module 'moduleFFI' for class VariadicInvoker not known ESC[0mESC[91mEnclosing class/module 'moduleFFI' for class Function not known ESC[0mESC[91mEnclosing class/module 'moduleFFI' for class Struct not known ESC[0mESC[91mEnclosing class/module 'rbffi_StructClass' for class InlineArray not known Enclosing class/module 'rbffi_StructLayoutClass' for class CharArray not known ESC[0mESC[91mEnclosing class/module "rbffi_StructLayoutCharArrayClass" for alias to_str to_s not known ESC[0mESC[91mEnclosing class/module 'moduleFFI' for module DataConverter not known ESC[0mESC[91mEnclosing class/module 'moduleFFI' for class StructByValue not known ESC[0mESC[91mEnclosing class/module 'moduleFFI' for class StructLayout not known ESC[0mESC[91mEnclosing class/module 'rbffi_StructLayoutClass' for class Field not known ESC[0mESC[91mEnclosing class/module 'rbffi_StructLayoutClass' for class Number not known ESC[0mESC[91mEnclosing class/module 'rbffi_StructLayoutClass' for class String not known ESC[0mESC[91mEnclosing class/module 'rbffi_StructLayoutClass' for class Pointer not known ESC[0mESC[91mEnclosing class/module 'rbffi_StructLayoutClass' for class Function not known ESC[0mESC[91mEnclosing class/module 'rbffi_StructLayoutClass' for class Array not known ESC[0mESC[91mEnclosing class/module 'moduleFFI' for class MemoryPointer not known ESC[0mESC[91mEnclosing class/module 'moduleFFI' for module NativeType not known
are those normal? Thanks!
On Tuesday, September 23, 2014 12:28 PM, Thibaud Lepretre notifications@github.com wrote:
Yeah my bad my patch works "sometimes"... The only solution I found is to add the following directive inside [program:cloudtunes-8000] and [program:cloudtunes-worker] startretries=10 startsecs=10 The goal is to increase the number of retries before giving up. With 10 retries on my docker env it work but you can tune it. — Reply to this email directly or view it on GitHub.
I got the same problem