PM2 - Autostart on Raspbian (Raspberry Pi) does not work - node.js

Ok guys,
this is driving me nuts... Can't get my nodejs application to autostart#boot on a raspberry pi...
Machine: Raspberry 2 (Raspbian Jessie)
Tried almost every possible solution I found on Google.
This is what I've ended up with:
Installed pm2
$ sudo npm install -g pm2
This will install it as a init.d script and run the application as pi user
$ sudo pm2 startup raspberry -u pi
[PM2] Generating system init script in /etc/init.d/pm2-init.sh
[PM2] Making script booting at startup...
[PM2] -raspberry- Using the command:
su -c "chmod +x /etc/init.d/pm2-init.sh && update-rc.d pm2-init.sh defaults"
[PM2] Done.
I've read that the script refers to the wrong .pm2 folder (looks in the root folder, not the user's folder) so I changed that
$ sudo vi /etc/init.d/pm2-init.sh
Changed export PM2_HOME="/root/.pm2" to export PM2_HOME="/home/pi/.pm2"
$ cd /opt/mycoolnodeproject
Starting my node project with pm2
$ pm2 start server.js -x --name "node-project"
Save active processes so it will restart them upon restart (if the pi crashes, it would save it on shutdown automatically)
$ pm2 dump
So now the server is up and running and works fine... until I reboot! I thought that pm2 would autostart my node application but for some reason it doesn't... :(
Any idea what the problem might be?
Btw: I've also tried to call startup like this sudo env PATH=$PATH:/usr/local/bin pm2 startup raspberry -u pi, but that didn't work either.
Regards,
Sascha

Mia's comment made me checking the issue list of PM2 again and someone figured out how to do it! :)
https://github.com/Unitech/pm2/issues/1654
The solution:
sudo pm2 startup systemd -u <username>
Works like a charm! :)
Sascha

I was able to get PM2 to start at bootup correctly on my RPi with this command:
sudo env PATH=$PATH:/usr/local/bin pm2 startup systemd -u pi --hp /home/pi
The --hp /home/pi part seemed to be the difference. That is what was left out of a lot of solutions I found that didn't work.

I also searched for days without success but then,
I got it to work quite simply.
In Raspian click Menu,Preferences,Main Menu Editor
Click Preferences and check Default applications for LXSession
Click OK and close main menu editor
Now click Menu and Under Preferences click on Default applications for LXSession
LXSession configuration opens
Click Autostart
Under Manual autostarted applications paste in your java command line
click add
close the LXSession configuration application and reboot your pi
your java app should run after reboot

Here's a workaround based on this article (the suggested workaround didn't help me):
Make a mini startup init.d script to resurrect the pm2 process yourself
#! /bin/sh
# /etc/init.d/pm2
#
# help documentation:
#https://debian-administration.org/article/28/Making_scripts_run_at_boot_time_with_Debian
pm2 resurrect
Make it executable
chmod 755 /etc/init.d/blah
Update system symbolic links
update-rc.d pm2 defaults
Reboot, go to your website (and look at the date; make sure it's not browser cached)

I'm going to describe the debug steps that led me to the solution, since I think that it can be usefull. If you just want the solution I invite you to go to the end of this answer.
Debug steps
In my case I was setting up pm2 startup like this:
sudo pm2 startup systemd -u pi
And it wasn´t working. pm2 just refused to start at boot. In order to know what was going on I followed this instructions.
Next I had a look at the systemctl units:
systemctl list-units
And saw this red line in the output
pm2-pi.service failed failed PM2 process manager
Then I had a look to the corresponding log (note the username at the end of the filename: pm2-pi)
journalctl -u pm2-pi
So the reason was that pi user had not enugh permissions to access the JSON module conf file.
May 28 12:36:52 raspberrypi pm2[534]: Error: EACCES: permission denied, open '/root/.pm2/module_conf.json'
Solution
I could have changed the json permissions but I decided to run PM2 as root user. If this is dangerous, please let me know.
sudo pm2 startup -u root

My issue was to do with user names, using root rather than my non-root user. I fixed it by editing the service file directly. There's probably a better way to fix it e.g. by running the startup command differently. But a simple work-around (manual file change) worked.
When I ran the startup command:
sudo pm2 startup systemd -u XXX
It created a file for the reboot service here:
/etc/systemd/system/pm2-XXX.service
In this file some of the paths are for root and not my user XXX:
Environment=PM2_HOME=/root/.pm2
PIDFile=/root/.pm2/pm2.pid
So I changed the paths to that of the correct user:
Environment=PM2_HOME=/home/XXX/.pm2
PIDFile=/home/XXX/.pm2/pm2.pid
And after a reboot the process starts up as expected.

Related

Centos7 unable to run #reboot command

I am not able to run reboot commands on my CentOS 7 machine.
For example I've created a script: /home/usr/myscript.sh (marked executable) with:
echo "hello world" > example.txt
When Im trying to run the script from terminal everything works good.
I tried to start the script on reboot at the end of the file:
nano /etc/crontab
I added:
#reboot /home/usr/myscript.sh
and on restart, nothing happen.
I also tried to edit file:
crontab -e
its looks like a new generated file, I've typed my command, and again nothing happend.
How can I run a command on CentOS at reboot?
I tried to insert that command on my Ubuntu machine, and everything was good and worked properly.
Anyone can advise on different way (maybe 3rd party program) that will help me to manage the reboot jobs?
Thanks for the help.
BTW, its might be duplicate, but I cant find any answer that helped me
In CentOS/RHEL 7, the systemctl utility replaces some older power management commands used in previous versions. The table below compares the older and new equivalent systemctl commands. The old commands listed in the table still exist for compatibility reasons.
Older Command systemctl equivalent Description
halt systemctl halt Halts the system
poweroff systemctl poweroff Powers off the system
reboot systemctl reboot Restarts the system
pm-suspend systemctl suspend Suspends the system
pm-hibernate systemctl hibernate Hibernates the system
pm-suspend-hybrid systemctl hybrid-sleep Hibernates and suspends the system
I was able to reach this out by adding a crontab file for my user.
with the following command:
crontab -u usrname filename
That allow me to run my scripts.
Thanks !

How to automatically execute shell script at startup boot on systemd Ubuntu 18.04

I want setup shadowsocks antumatically start at startup on ubuntu 18.04
See this.
My shell is shadowsocks.sh
#!/bin/bash
if [ -f /usr/bin/sslocal ]; then
sudo /usr/bin/sslocal -c /etc/shadowsocks/config.json -d restart -v
fi
It runs well
and I setup with systemctl
like this shadowsocks.service
[Service]
ExecStart=/usr/local/bin/shadowsocks.sh
[Install]
WantedBy=default.target
Alias=ss.service
when I run
sudo systemctl start ss.service
I can see shadowsocks logged "started"
but I can't see shadowsocks started and I can't use google.
I'm chinese, I'm sorry for my bad English, I wish someone can see my question
delete -d in shell script
everything is ok
Easiest way is via ubuntu tweaks tool. Just install tweak tool and add ur applicaiton via the GUI. Example
http://xtrace.blogspot.com/2020/02/run-script-at-startup-of-ubuntu.html

Why is my script to start UWSGI not functioning at bootup?

I wonder if you can help.
I am running the following versions:
OS: SMP Debian 3.2.81-1 x86_64
uWSGI: uWSGI 2.0.11.2
I installed uWSGI manually, as I want to use a specific version. Using the following commands: -
apt-get install build-essential psmisc python-dev libxml2 libxml2-dev python-setuptools
cd /opt/
wget http://projects.unbit.it/downloads/uwsgi-2.0.11.2.tar.gz
tar -zxvf uwsgi-2.0.11.2.tar.gz
mv uwsgi-2.0.11.2/ uwsgi/
cd uwsgi/
python setup.py install
I am trying to replicate the setup on another server that the project is already working on in a live environment (I am essentially setting up a test server environment).
The original server has uWSGI running on boot. To figure out how this is happening, I used
htops
I've been able to identify that uWSGI is running on the existing server with a set of command line switches. I've managed to track down the script that initialises uWSGI with these switches in the init.d folder.
I copied this script to my test server, and ran it using
service script.sh start
After various troubleshooting, mainly involving permissions on socket folders etc, now when I run this script it starts, and if I run htop I can see uWSGI is running and it has the exact same command switches I need.
I thought simply putting the script in init.d and giving it execute permission
chmod +x script.sh
Would be enough so that it starts when the server is switched on... but this appears to not be the case. Because when I issue
reboot
At the terminal, the terminal reboots but when I go into htops, and check for the uWSGI process it is not running.
If however directly after reboot I issue the following command
service script.sh start
The service starts just fine, and I can once again see it in htops.
Research online lead me to the suggestion that I should try to set the script to run automatically using chkconfig. I installed chkconfig using
apt-get chkconfig
and then ran the following command
chkconfig --list
I noticed that all the runtime levels where set to off for the script I am trying to get to execute on boot.
I ran the following command
chkconfig /etc/init.d/script.sh on
And now when I check the script runtime switches with chkconfig, it shows me the following output for my script:
script.sh 0:off 1:off 2:on 3:on 4:on 5:on 6:off
However when I reboot the uWSGI process is still not starting.
Yet if I simply type
service script.sh start
At the terminal the service runs ok, and uWSGI runs fine.
How can I set the script to run when the server restarts?
Edit:
Further research on the live server that is working fine, has determined that it does not appear to be using systemd to launch uWSGI on startup. I logged into the live server and while there is a
/etc/systemd
folder, it has just one folder in it system and no files. The system folder has the following files in it:
multi-user.target.wants sockets.target.wants syslog.service
So there does not appear to be anything uWSGI related in here.
Also what is making me think this is likely something to do with the
/etc/init.d
folder, is that when I run htop and examine the running services (or daemons) not quite sure of the correct terminology in linux. uWSGI is showing in here as running with a signature of command line switches, and the script I have found in /etc/init.d has this exact uWSGI command and same signature of switches, so I'm fairly convinced this is the part of the system that is starting the uWSGI daemon , I just can't figure out what I need to do , to get it to run apart from copying the same file to /etc/init.d on the new server and giving it execute permission.
The OS of the live server is :
SMP Debian 3.2.73-2+deb7u1 x86_64
and the OS I am running on the new server is
SMP Debian 3.2.81-1 x86_64
So they seem fairly similiar? Although I'm not sure how significant the 8 incremements in the least significant digits in the version number is.
On the new server there is no /etc/systemd folder , and on the live server there is a /etc/systemd as explained above. So it does appear to have been installed seperately to the main OS install (as I have a later version of Debian and it wasn't installed on my system by default) - so perhaps there is something related to systemd that is causing the script to start on the live server, but I'm not too sure.
Jessie
In the recent Debian (Jessie) the initv scripts do not work the way they did. And given your kernel version you are not running a Debian that uses initv scripts. The current Debian uses systemd and scripts in /etc/rc.d are run by compatibility features of systemd (the service command is now a systemd command that tries to behave like the old initv command).
You have two options:
Add a line calling the script from /etc/rc.local:
/etc/rc.d/script.sh
This is a rather dirty fix, since it depends on another compatibility feature of systemd. Also, the location of the script does not matter anymore.
Write a full systemd service for uwsgi (this is what I do, and what is recommended by the uwsgi documentation). You would need to create a file called /etc/systemd/system/uwsgi.service with a content similar to:
[Unit]
Description=uwsgi emperor
After=rsyslog.service
[Service]
PIDFile=/run/uwsgi-emperor.pid
ExecStart=/bin/uwsgi --ini /etc/uwsgi/emperor.ini
ExecReload=/bin/uwsgi --reload /run/uwsgi-emperor.pid
ExecStop=/bin/uwsgi --stop /run/uwsgi-emperor.pid
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all
[Install]
WantedBy=multi-user.target
I use the emperor mode (which is also the mode recommended by uwsgi for use with systemd), although it is possible to hack it to run a single process uwsgi (see further reading below).
You will also need to enable the service to be used by the multi-user.target, which will run at boot. You need to perform this as root:
systemctl enable uwsgi.service
And uwsgi will start with the next boot (it will not start straight away, to make it start you need systemctl start uwsgi.service).
Further reading:
The Arch linux wiki about systemd is very thorough
The Debian wiki on systemd is good, but outdated in some places (notably, it tells you that you need to install it which is not the case in Jessie)
Weezy
You're mixing things up a little there: chkconfig is a script of the RedHat family of OSes. Making it work for Debian was not easy in the past, and I do not believe it is easy to do so now.
Weezy still uses the initv rc.d folders alright, for each runlevel one rc.d folder:
/etc/rc.d/rc0.d/
/etc/rc.d/rc1.d/
/etc/rc.d/rc2.d/
/etc/rc.d/rc3.d/
/etc/rc.d/rc4.d/
/etc/rc.d/rc5.d/
/etc/rc.d/rc6.d/
You can check the runlevel you are in with the (appropriately named) runlevel command. Then you need to check whether there is a softlink to the script in the correct /etc/rc.d/rc*.d folder. If there is no softlink to the script you need to add it with something of the lines:
ln -s /etc/rc.d/init.d/script.dh /etc/rc.d/rc$(runlevel | cut -d ' ' -f 2).d/script.sh
And that is almost all about how initv scripts work. If you are going into runlevel 2 when the machine boots (I believe that's the default on Debian), what init performs is simply service <script> start for every file in /etc/rc.d/rc2.d.

How to run node.js process with forever logging on ubuntu reboot?

There was a topic how to run process with forever and logging.
How to run node.js process with forever and logging?
How to do this in crontab?
Currently I have this in crontab:
#reboot . $HOME/.bashrc
#reboot forever start /path/my_server.js
And in my home directory .bashrc there is a line
export DEBUG=*
Node server starts. But it does not make logs as if I would start manually.
How to fix that?
Update:
Cron is for the same user as if I started manually.
I guess you should use source $HOME/.bashrc
Edit:
You can use https://github.com/chovy/node-startup which it is a boilerplate for an init script, just change few things there and copy to init.d and then with the command update-rc.d node-app defaults the process will start whenver you reboot, no need for cron.
you find the manual in the repository. very easy

How to make a node application on Digitalocean run constantly?

I recently got a node application up and running on digitalocean's droplet. Everything is working properly, if I go forever on the server javascript file I can navigate to the site and it works.
If I close the terminal window in which I am ssh-ing, the site is no longer available, which is expected of course. But my question is, how can I run the forever as a daemon of sorts?
I could not find the answer anywhere, which is really strange...hope somebody here might be able to help me
Generally forever should continue running if you set it up as a background task and don't close it. Unfortunately if the server needs to restart (which can happen often), you need something to get it started again.
An alternative to forever is pm2, pretty much the same thing. There is a tutorial on how to set up your production server here. Here is an excerpt from the site for just the pm2 part, as I assume you got everything else sorted:
Install PM2
Now we will install PM2, which is a process manager for Node.js applications. PM2 provides an easy way to manage and daemonize applications (run them as a service).
We will use Node Packaged Modules (NPM), which is basically a package manager for Node modules that installs with Node.js, to install PM2 on our app server. Use this command to install PM2:
sudo npm install pm2 -g
Manage Application with PM2
PM2 is simple and easy to use. We will cover a few basic uses of PM2.
Start Application
The first thing you will want to do is use the pm2 start command to run your application, hello.js, in the background:
pm2 start hello.js
This also adds your application to PM2's process list, which is outputted every time you start an application
PM2 automatically assigns an App name (based on the filename, without the .js extension) and a PM2 id. PM2 also maintains other information, such as the PID of the process, its current status, and memory usage.
Applications that are running under PM2 will be restarted automatically if the application crashes or is killed, but an additional step needs to be taken to get the application to launch on system startup (boot or reboot). Luckily, PM2 provides an easy way to do this, the startup subcommand.
The startup subcommand generates and configures a startup script to launch PM2 and its managed processes on server boots. You must also specify the platform you are running on, which is ubuntu, in our case:
pm2 startup ubuntu
The last line of the resulting output will include a command (that must be run with superuser privileges) that you must run:
Output:
[PM2] You have to run this command as root
[PM2] Execute the following command :
[PM2] sudo env PATH=$PATH:/usr/local/bin pm2 startup ubuntu -u sammy
Run the command that was generated (similar to the highlighted output above) to set PM2 up to start on boot (use the command from your own output):
sudo env PATH=$PATH:/usr/local/bin pm2 startup ubuntu -u sammy

Resources