Question: How can I confirm whether or not my "Dedicated Server" is running properly?
Background: I am working to get a 'Dedicated CoreNLP Server' running on a stand-alone Linux system. This system is a laptop running CentOS 7. This OS was chosen because the directions for a Dedicated CoreNLP Server specifically state that they apply to CentOS.
I have followed the directions for the Dedicated CoreNLP Server step-by-step (outlined below):
Downloaded CoreNLP 3.7.0 from the Stanford CoreNLP website (not GitHub) and placed/extracted it into the /opt/corenlp folder.
Installed authbind and created a user called 'nlp' with super user privileges and bind it to port 80
sudo mkdir -p /etc/authbind/byport/
sudo touch /etc/authbind/byport/80
sudo chown nlp:nlp /etc/authbind/byport/80
sudo chmod 600 /etc/authbind/byport/80
Copy the startup script from the source jar at path edu/stanford/nlp/pipeline/demo/corenlp to /etc/init.d/corenlp
Give executable permissions to the startup script: sudo chmod a+x /etc/init.d/corenlp
Link the script to /etc/rc.d/: ln -s /etc/init.d/corenlp /etc/rc.d/rc2.d/S75corenlp
Completing these steps is supposed to allow me to run the command sudo service corenlp start in order to run the dedicated server. When I run this command in the terminal I get the output "CoreNLP server started" which IS consistent with the the start up script "corenlp". I then run the start command again and get this same response, which is NOT consistent with the start up script. From what I can tell, if the server is actually running and I try to start it again I should get the message "CoreNLP server is already running!" This leads me to believe that my server is not actually functioning as it is intended to.
Is this command properly starting the server? How can I tell?
Since the "proper" command was not functioning as I thought it should, I used the command sudo systemctl *start* corenlp.service and checked the service's status with sudo systemctl *status* corenlp.service. I am not sure if this is an appropriate way in which to start and stop a 'Dedicated CoreNLP Server' but I can control the service. I just do not know if I am actually starting and stopping my dedicated server.
Can I use systemctl command to operate my Dedicated CoreNLP Server?
Please read the comments below the originally posted question. This was the back and forth between #GaborAngeli and myself which lead my question/problem being solved.
The two critical steps I took in order to get my instantiation of the CoreNLP server running locally on my machine after following all the directions on how to setup a dedicated server, which are outlined on Stanford CoreNLP's webpage, are as follows:
Made two modifications to the "corenlp" start-up script. (1) added sudo to the beginning because the user "nlp" needs permissions to certain files on the system (2) changed the first folder path from /usr/local/bin/authbind to /usr/bin/authbind. authbind installation must've changed since the start up script was written.
nohup su "$SERVER_USER" -c "sudo /usr/bin/authbind --deep java -Djava.net.preferIPv4Stack=true -Djava.io.tmpdir_"$CORENLP_DIR" -cp "$CLASSPATH" -mx15g edu.stanford.nlp.pipeline.StanfordCoreNLPServer -port 80"
If you were to attempt to start the server with the change above you would not successfully run server because sudo usage requires a password input. In order to allow sudo privileges without a required password entry you need to edit the sudoers file (I did this under the root user b/c you need permissions to change or even view this document). my sudoers file was located in /etc. There is a part that says ## Allows people in group wheel to run all commands and below that is a section that says ##Same thing without a password. You just need to remove the comment mark (#) form in front of the next line which says %wheel ALL+(ALL) NOPASSWD: ALL. Save this file. BE CAREFUL IN EDITING THIS FILE AS IT MAY CAUSE SERIOUS ISSUES. MAKE ONLY THE NECESSARY CHANGE OUTLINED ABOVE
Those two steps allowed me to successfully run my dedicated server. My system runs on CentOS 7.
HELPFUL TIP: From my discussion with #GaborAngeli I learned that within the 'corenlp' folder (/opt/corenlp if you followed the directions correctly) you can open the stderr.log file to help you in trouble shooting your server. This outputs what you would see if you were to run the server in the command window. If there is an error it is output here too, which is extremely helpful.
Related
I have a little node application on a server (node mailer) that I run by going to its source folder and executing npm start. I figured the best way to run this automatically would be to create a my_script.sh file and drop it in the init.d directory of my debian box. Inside the file (below the !#/bin/bash line), the code to execute is
'/opt/mycode/source/npm start'
I save the line to the .sh file and restarted the machine, but so far haven't got it to work. My question is: is this even how you start a script like this (using that command and an .sh file)? It does start normally when I do it manually (when I navigate to it and run npm start in the terminal). I included the single quotes around it because of the space between npm start. Also, if I want to verify that it worked, which process would I look for other than just pinging my smtp mailer? Finally, I know I need to run:
update-rc.d my_script.sh defaults
but I was also confused at to whether I had done this correctly either (is it just the name of the file that goes there or the file plus the extension)?
The script that you leave on the init.d folder should not have any extension and should have functions to start, stop and get the status of the service (your application).
I'll leave a link with an example as well as with some basis in order to build the Linux service script.
I would suggest reloading the daemon with systemctl daemon-reload in order to refresh the Linux service files once you add a new one.
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.
While creating an rpm spec file I have created a new user and group in the %pre section. This new user does not however have permission to login from from shell for security purposes. Now when I install the rpm this new user is successfully created. However, I wish to start the installed rpm service with the newly created user. Currently I simply write; 'filePath/file.exe file.cfg' to execute the file.exe with its configuration file i.e. file.cfg in my 'init.d' file to start the service. How can I modify this command to start the same service but with the user that I created while installing the rpm? Basically I want to execute the program in my init.d file but through a different user, like I would have done with sudo if my required user was the super user. Any feedback will be highly appreciated.
Your initial starting point both for installing the rpm and for running the service is privileged. For instance, on my CentOS 6 machine, I see in /etc/passwd
games:x:12:100:games:/usr/games:/sbin/nologin
but running as root, I can do this:
$ sudo -u games /bin/sh
sh-4.1$ echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin
sh-4.1$ id
uid=12(games) gid=100(users) groups=100(users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
sh-4.1$ cd
sh-4.1$ pwd
/usr/games
In your service script, you can use sudo to run a given process as another user (though a quick check of the same machine does not show this being done).
#msuchy points out that runuser may be preferable. I see that this is relatively recent (according to Ubuntu runuser command?, appeared in util-linux 2.23 -- lacking a date makes release notes less than useful...). The oblique comments in its documentation about PAM make it sound as if this circumvents some of the security checks. Perhaps someone has a better comment about that.
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've got an SVN instance installed on a free EC2 AWS server. In short: I'm using LAMP.
Using what I read in this article and encountered the "you need a TTY" error as mentioned in the comments. I followed the second resource and it cleared the error message, but doesn't seem to be executing the script. When I manually run the script, however, it works.
Any clue what I'm missing?
When I followed the second resource to fix the TTY error I changed the contents of my /svn/repository/hooks/post-commit script from:
#!/bin/bash
sudo /usr/local/bin/svn-post-commit-update-mysite 1>&2
to:
#!/bin/bash
su –session-command=”/usr/local/bin/svn-post-commit-update-mysite 1>&2″ dynamic &
First possible issue:
You cannot rely on the value of the $PATH variable inside the hook. This means you need to specify complete paths for all executables.
In particular, "su" is a program located in "/bin/sh" in most distributions. To be sure, type
type su
Next possible issue:
Is your subversion server being run as root? su will try to ask for password if run by other users, and will fail if it's not being run interactively - even if the user is in the sudoers file!
If you are using Apache+DAV, this means the apache service must be run as root for this to work (instead of www-data), which is a serious security problem.
You probably don't need to use su or sudo at all if all of the files are owned by the same user (www-data, for instance). You can change the ownership of the site files with something like
sudo chown -R www-data:www-data /var/www/<my-project>
And then remove the sudo and su from both the hook and the svn-post-commit-update-mysite file.
My best guess would be that something in your script depends on the PATH environment variable. Subversion runs hooks in an empty environment for security reasons. So you need to either setup the environment in your shell script or use absolute paths.
You might want to read the Subversion book entry on implementing hook scripts. The particular issue I mentioned is explained in the information block.