How do I auto start a javascript server with pm2? I normally run this command to start the javascript server:
oneanime config.json
so what would the command be to run in pm2?
I'm temporary using a bash script to run it in pm2 but I prefer run the command directly in pm2 instead of relying bash script.
Related
I'm using pm2 to execute a process:
pm2 start "env-cmd -f ../bare-metal.env nest start --watch"
This works perfectly on Linux, however, on Windows I'm getting the following error:
[PM2][ERROR] Script not found: C:\Users\username\projectFolder\env-cmd -f ..\bare-metal.env nest start --watch
It seems like pm2 is prepending the directory. If I execute the command without pm2 it works well so the problem seems to be with pm2 on Windows.
Is it possible to fix this behavior so pm2 executes the command just as the command line does, without prepending anything?
I tried to set up a wordpress solution (installing by myself and not using an official image). I have one container with apache, php and mariadb-client (to interrogate mariadb-server from another container)
I have another container with mariadb on it.
I use wp-cli to configure wordpress website but when i build my docker image, I can't execute the command (inside sh file) which is
wp core config --allow-root --dbname=$MYSQL_DATABASE --dbuser=$MYSQL_USER --dbpass=$MYSQL_PASSWORD --dbhost=172.20.0.2 --dbprefix=wp --path=/var/www/html/wordpress
because my mariadb container isn't up.
So I tried to run this script with entrypoint parameters and when I do my docker-compose up, my script is played and I have the message:
apache-php_SDV | Success: Generated 'wp-config.php' file.
apache-php_SDV | Error: The 'wp-config.php' file already exists.
My script is played every second, I tried to use CMD before and it doesn't work, it's like CMD wasn't run
I have the same result if I want to put CMD after ENTRYPOINT, I can run my script only when both containers are up.
I also tried to use command on my docker-compose.yml but not helpful. Does anyone have a solution?
I resolve myself, it could be useful, i kill PID 1 who run my first script and i run another script who start apache and take PID 1 to the container, there is the code :
#!/bin/bash
set -o errexit
case "$1" in
sh|bash)
set -- "$#"
;;
*)
set -- apache2ctl -D FOREGROUND "$#"
;;
esac
exec "$#" ```
So i have an app that was built for me and I need to keep it running. but the app was built with the instructions of running it with
npm run start
I am trying to figure our how to do this using either the ecosystem.config.js or command line arguments.
I tryed
pm2 start npm --name "myApp" -- run "start-test"
But the pm2 log shows an exit code of 1.
So what is the propepr way to accomplish this?
I have a sidekiq worker that executes some JRuby code to connect and pull data from a remote server. It works fine by running on terminal:
bundle exec sidekiq
But on production I want to run the worker in background by passing -d option:
bundle exec sidekiq -d -L log/sidekiq.log
It doesn't work and returns the following:
ObjectSpace is disabled; each_object will only work with Class, pass -X+O to enable
Any other option I need to pass in order to run the sidekiq in background ?
even if you enable ObjectSpace it will fail since you can not fork in JRuby.
you can not use the -d option, use system alternatives such as nohup
Use systemd or upstart instead of daemonizing by hand.
https://github.com/mperham/sidekiq/wiki/Deployment#daemonization
I have been working on setting up a self contained rails app in a single container. This means getting both rails and a data persistence service running at the same time in one container. In our case, that means mysql.
However, I ran into multiple issues getting this working, because mysql wasn't running.
During the build step, if I had RUN mysqld and then a separate RUN rake db:create step, rake would crash, because mysql was down.
So I worked around this by wrapping the two commands into a script. However, at runtime, rails would fail to startup because mysql wasn't running.
My intuition says that if mysql is started during the build, it should be available at runtime, but I did not have that experience. Starting the rails server had to be wrapped in a script with another call to mysqld.
Here's the dockerfile:
FROM ruby:2.2
RUN mkdir -p $APPDIR
WORKDIR $APPDIR
ADD Gemfile* $APPDIR/
RUN bundle install
RUN apt-get update -qq
RUN DEBIAN_FRONTEND=noninteractive apt-get install -y -qq nodejs mysql-server --no-install-recommends
RUN rm -rf /var/lib/apt/lists/* # */ broken syntax highlighting
COPY . $APPDIR
RUN script/mysql-setup.sh # contents are: mysqld_safe; rake db:create; rake db:migrate
EXPOSE 3000
CMD ["script/rails-launcher.sh"] # contents are: mysqld_safe; rails s
Do I need to do something differently in the Dockerfile? Why isn't mysql up at runtime?
My intuition says that if mysql is started during the build, it should be available at runtime
This is incorrect. Docker will start the service for you and perform the subsequent steps you've defined in the same RUN command, but then it bundles everything up into an intermediate image for subsequent commands. The image doesn't have a known state of running processes, only whatever is required for startup such as init.d scripts.
Your solution would be to use a server startup script or continue to invoke mysqld_safe as you do in your CMD line.
A good idea is to use supervisord to maintain all of your services in a non-daemon mode. Phusion also provides a nice base image with a runit initializer script.
Eventually, you'll come to see how the power of Docker lies in how you can actually break MySQL out of your Rails app container and run it in an entirely different container linked together.
The RUN Command is used to configure your image, each time it is called, a new layer is created with the results of run command. So, if you need to configure your database on the image build step, you have 2 solutions: you can call a number of command in a single RUN call, like
RUN /bin/bash -c "mysqld_safe" && "rake db:create" && "rake db:migrate"
Or via call of single script, as you did.
In both cases, you have to inderstand, that the fact, you runned something during the image build, it'll not run automatcally on the container start up. So, you have to start your database server manually on container start up.