Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Marathon and chronos processes are not restarted #58

Open
AlexeyKupershtokh opened this issue May 8, 2015 · 10 comments
Open

Marathon and chronos processes are not restarted #58

AlexeyKupershtokh opened this issue May 8, 2015 · 10 comments

Comments

@AlexeyKupershtokh
Copy link

When you do vagrant up on the multinodes cluster, then do vagrant halt marathon and vagrant up again, neither marathon nor chronos processes are started within the marathon VM.
One have to destroy the vm instead and spend more time on vagrant up each time.
PS: I don't see anything related to chronos or marathon in the marathon:/etc/init/ or marathon:/etc/init.d/

@goodgoblin
Copy link

For what it's worth -- take a look at the Vagrant file.

nohup /opt/marathon/bin/start --master zk://localhost:2181/mesos --zk_hosts localhost:2181 --event_subscriber http_callback > /var/log/marathon/nohup.log 2> /var/log/marathon/nohup.log < /dev/null &

You can use that to start marathon once you ssh into the box.

You can probably also use

vagrant provision

to get it to run again.

@everpeace
Copy link
Owner

Or you can vagrant up --provision to execute provision phase again. This shouldn't happen mesos master/slave process' restart when mesos related configuration hasn't been changed.

@goodgoblin
Copy link

I think he is saying that marathon doesn't restart -- mesos master and slave seem to start fine though.

@everpeace
Copy link
Owner

@goodgoblin Once vm provisioned, mesos-master/slave process was registered to upstart. So you needn't to worry about. But, marathon process was started bash provisioner in vagrant-mesos as you noticed. So, I wanted to point out that if they wanted start marathon process by vagrant command, they need to vagrant up --provision. However this command also spawns chef provisioner. So they might be worry about happening unnecessary restart of mesos-master/slave processes. I wanted to point point out this thing.

@AlexeyKupershtokh
Copy link
Author

Hello guys. Thank you for your help. I'll check these approaches shortly.
But Isn't it worth to make marathon and chronos start by the upstart as well?

@goodgoblin
Copy link

@everpeace thanks -- that makes sense.
@AlexeyKupershtokh adding to upstart would be a fine idea, but it may be tricky b/c of initialization order?

@granthbr
Copy link

I'm having an similar issue. Marathon and Chronos don't start. So I try

vagrant provision

The vagrant box restarts then says there is problem with the shares and I need to do

vagrant reload

I do that, then the services do not start again.
So, I then i try

nohup /opt/marathon/bin/start --master zk://localhost:2181/mesos --zk_hosts localhost:2181 --event_subscriber http_callback > /var/log/marathon/nohup.log 2> /var/log/marathon/nohup.log < /dev/null &

Which does start the service on the box, but, when I attempt to load any Docker service it never properly loads.
Any thoughts?

@corecanarias
Copy link

I had the same issue, I wasn't able to provision all boxes, what worked for me was first do vagrant up, confirm that marathon/chronos doesn't start and then provision only that machine:

vagrant provision marathon

@granthbr
Copy link

granthbr commented Dec 7, 2015

I'll give that a shot. Thanks @corecanarias

1 similar comment
@granthbr
Copy link

granthbr commented Dec 7, 2015

I'll give that a shot. Thanks @corecanarias

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants