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 !
Related
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
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.
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.
What are the command to start, restart and stop gearman?
So far I know:
gearadmin --shutdown # stop
gearmand -d # I believe it is to restart. Not sure.
Any idea for managing gearman?
If you want to restart the gearmand, then you should use the shell script gearman-job-server. Type the command as sudo service gearman-job-server restart which STOPs and STARTs the server
---------------------- More Information If you need it -----------------------
I assume you have some small confusion over here. It's all because of Terminologies. The name of the application is Gearman which is a Message-Queue System.
I am answering with the assumption tha you are working with Linux OS.
When you try installing the Gearman, the application that gets installed is gearmand which is a Job-Server/executable file. Something like Apache for example.
Refer the link http://manpages.ubuntu.com/manpages/precise/en/man8/gearmand.8.html for the command reference.
Then what's the gearman? gearman is the Client Program/Application, with which you can talk to the gearmand. With gearman you can run client and worker functions from the command line.
Refer the link http://manpages.ubuntu.com/manpages/precise/en/man1/gearman.1.html for the command reference.
So what's gearadmin? It's the tool which allows you to run Admin commands against your gearmand
Refer the link: http://manpages.ubuntu.com/manpages/precise/en/man1/gearadmin.1.html
Now coming to your questions about the command gearmand. From the shell if you run the command as gearmand, the Job Server starts and gets attached to your Shell Process. For ex: if you run php from shell the php runs and starts waiting for your commands right? Same way. If you want to run Gearmand as a background process, then you should run with the param as -d which makes it run as a daemon
So gearmand -d makes it run as Daemon. Not a restart command.
Hope this helps to answer your question and also to clarify in case if you have any confusion over the naming.
How to STOP Gearman Server
==> gearadmin --shutdown
How to START Gearman Server
==> gearmand -d
The popular answer seems to be a bit old, so if you get Failed to restart gearman-job-server.service: Unit not found. when trying to restart the old way, try just sudo service gearmand restart. That's how it seems to work on a CentOS with latest version of gearman.
For restarting the workers on the same system there seems to be a sudo gearmanw-control restart command avaliable.
I am trying to start GUI application with upstart script on CentOS. I have test script located /etc/init/ folder.
start on desktop-session-start
stop on desktop-shutdown
respawn
script
export DISPLAY=:0
sleep 5
exec /.1/Projects/UpstartTest/start.sh &
end script
start.sh scripts is running binary files for GUI application.
After reboot my computer. When I typed:
[root#mg-CentOS ~]# initctl status test
test stop/waiting
So my upstart is not runnig. When i type
initctl start test
manually it works fine without any problem.
How can I run this upstart script after user login (desktop started) ? I am trying to find detailed documents for CentOS for upstart but there is no.
For this purpose, you can use the update-rc tool, which is builtin on linux distributions. It basically creates a symbolic link for the script you want to be executed at startup, or some other OS states, on the folder rc.X, where X is the number of the folder that determines a state that you want.
You may want to have a look at this answer: Update-rc.d custom script running too late, and also runs at shutdown
More information about can be found here:
http://www.linux.com/news/enterprise/systems-management/8116-an-introduction-to-services-runlevels-and-rcd-scripts
Detailed information about the CentOS booting process can be found here: https://www.centos.org/docs/5/html/Installation_Guide-en-US/s1-boot-init-shutdown-process.html;
the rc is being explained at this document as well.