ranganathanm
commented
9 years ago In general, this is a good idea. Starting with shell scripts is error prone.
Do you want these to auto start on boot? (If you are running in a VM that makes sense - when you restart the VM all services will restart). You could spin up a VM and have a fully running MSOD with no extra configuration needed. That ought to sell like hot cakes :-)
I am re-writing streaming to be scalable. The version you have is thread based and will not efficiently use the available processing resources (due to python threading problems). There will be in fact as many streaming daemons as there are sensors (one per stream) for scalability. So the stopping of the service has to do what stop-gunicorn.sh does (I have yet to push my latest changes -- still testing). Not sure why you'd want to run services with different user IDs. You certainly don't want to be running as root.
To add to your list :
service nginx start
From: Douglas Anderson notifications@github.com Sent: Friday, April 3, 2015 5:33 PM To: usnistgov/SpectrumBrowser Subject: [SpectrumBrowser] Start services via init.d (#155)
We got streaming running yesterday after a bit of a struggle. One of the issues was the start_gunicorn.sh script was being run as root, causing memcached to throw an error and a snowball of other subtle problems.
We came up with a short term solution, but I think there's a need to create a more robust solution for getting the proper services started with the correct permissions/in the correct order, etc. I'd like to propose transitioning service startup scripts to init.d.
There are a number of benefits:
- Better OS integration for controlling/monitoring services
- Each service is started under its own user for better security
- init.d skeleton scripts exist for most services (e.g., Redhat/Centos gunicorn init.d script: https://gist.github.com/xspager/1511911).
The only penalty for this would be: a) need to modify the current start scripts to use init.d script conventions, and b) need to "install" those scripts into /etc/init.d.
The part about installing could be easily handled with a standard Makefile with an "install" build rule that simply copies a few files into /etc/init.d/. Actually, as long as we're making a simple Makefile, we could also have a default build target that runs the ant build..., then, installing/upgrading a starting the server would look like this:
$ git pull $ cd $SPECTRUM_BROWSER_HOME $ sudo make install # this will automatically run the build target if files changed $ sudo service mongod start $ sudo service memcached start $ sudo service gunicorn start $ sudo service streaming start
This is just a preliminary discussion issue: any thoughts on if this would this be a good way to move forward?
Reply to this email directly or view it on GitHubhttps://github.com/usnistgov/SpectrumBrowser/issues/155.
djanderson
We got streaming running yesterday after a bit of a struggle. One of the issues was the start_gunicorn.sh script was being run as root, causing memcached to throw an error and a snowball of other subtle problems.
We came up with a short term solution, but I think there's a need to create a more robust solution for getting the proper services started with the correct permissions/in the correct order, etc. I'd like to propose transitioning service startup scripts to init.d.
There are a number of benefits:
The only penalty for this would be: a) need to modify the current start scripts to use init.d script conventions, and b) need to "install" those scripts into /etc/init.d.
The part about installing could be easily handled with a standard Makefile with an "install" build rule that simply copies a few files into /etc/init.d/. Actually, as long as we're making a simple Makefile, we could also have a default build target that runs the ant build..., then, installing/upgrading a starting the server would look like this:
This is just a preliminary discussion issue: any thoughts on if this would this be a good way to move forward?