Having to manage a few production servers over different Linux distributions, I find it hard to remember the exact name of the service to restart/stop.
Is there anyway systematic way to determine the name of a running service, and subsequently being able to run
service <service name> status/stop/reload/start
commands?
Generally, programs that execute tasks in the background are normally known as “services” and “daemons”.
We can use "service" or "systemctl" to manage these servcies.
Example:
-service service-name start
-systemctl start service-name
Mostly custom service files will be at "/etc/init.d/" directory and custom systemd files will be at "/etc/systemd/system/" directory
for centos 7 use
systemctl list-unit-files
Related
I have a docker based application written in Java which calls a shell script to collect data. I want to add a few commands in this script to collect host machine/VM data like below :
firewall-cmd --list-all >> firewall.txt
journalctl >> journal.log
hostnamectl >> hostname-config.txt
iptables-save >> iptables.txt.
As these commands/resources are not directly accessible to the container, Is there any way I can achieve this? Basically what I am looking for is a way to access/run commands on host from inside the container. If yes, please answer with examples associated with any of the above commands.
A principal design goal of Docker is that processes in containers can't directly run commands on the host and can't directly access the host's filesystem, network configuration, init system, or other details.
If you want to run a detailed low-level diagnostic tool on this system, it needs to run directly on the host system, and probably as root. It can't run in a container, virtual machine, or other isolation system.
Is it possible to run a systemd session below the user session with unit files in a subdirectory and not installed in ~/.config/systemd? I'm developing a system consisting of different services (implemented in C++), some of which depend on each other. Currently, they're run from a bash script and all write to stdout. I would love to be able to start them from the build directory, e.g.
# enter build directory
cd /path/to/project/build
# start services
systemd --root ./systemd-units &
# check status of services
systemctl --root ./systemd-units status
# check log output of services
journalctl --root ./systemd-units
Unfortunately no such option exists and I couldn't find any alternative. I don't want to use docker because it makes debugging unnecessarily difficult.
Is there a way to do what I want with systemd? I looked into other systems and runit seems to be able to do what I want but is unlikely to be used in the final product.
It sounds like you may want to use the link feature of systemctl, so you can link units that are not the search path into the search path.
There is any way to download a file from google managed VM docker?
we lost one that is in production version and I want to download it to my computer but I cant find the app path
It should be possible.
First, determine the GCE instance that runs your version. The name of the version should be part of the instance name. If your version has multiple instances, you may have to try all of them (or if your file was part of the application, any of them may work).
From the Cloud console, you can switch it from "Google managed" to self-managed.
Next, use gcloud compute ssh <instance name> to ssh to the instance.
Next, run docker ps to find the container running your application code. You should see a few side-car containers like nginx, but if you look through the names of the containers you should see one for your application.
Finally, you could docker exec -it <container id> -- bash to create a shell on the instance. Or instead of bash, perhaps run a cat command or whatever else you need to do to recover your file.
I wish to know how can I schedule a custom script to run whenever I restart a service.
My use case is that I have to run several commands whenever I restart my Tomcat Service. I want to know if there is a way I can write a script and schedule it to run whenever I restart the Tomcat service.
I have setup the tomcat script as a systemd service. I am using Cent OS 7 x64.
I have been able to achieve this by creating another service and incorporating the Tomcat service's start stop in the new service. The new service acts as a wrapper service which first starts tomcat and then executes the commands that we need to run as soon as tomcat starts.
Then while stopping, it stops tomcat and runs clean up commands.
EDIT: I found another way of doing this on unix & linux stackexchange.
Simply create an new systemd .service file in /etc which includes and overrides part of the one in /lib. For example, create /etc/systemd/system/tomcat.service to contain
.include /lib/systemd/system/tomcat.service
[Service]
ExecStartPre=/home/meuh/myscripttorun some pre args here
ExecStartPost=/home/meuh/myscripttorun some post args here
Any ExecStartPre lines will be executed before the ExecStart line, and similarly any ExecStartPost will run after tomcat has started.
my group and I are running a server that is based upon Django and uses mod_wsgi to run an Apache server. We will not be working on this project after it is over, so I am attempting to set up cronjob similar functionality to check if the apache server has shut down(system restart or power failure), and if it has, will restart the server for me. I've found documentation on how to check if an apache server is down and restart the server if it is, but our server uses https and thus our start command is pretty verbose.
Can I simply use the functionality provided in these examples:
https://askubuntu.com/questions/277389/cron-job-to-restart-apache
https://www.digitalocean.com/community/tutorials/how-to-use-a-simple-bash-script-to-restart-server-programs
Or do I need a much more complicated process to make this happen?
The command we use to initially start the server is
python manage.py runmodwsgi --host 0.0.0.0 --port 8001 --https-port 8000 --ssl-certificate (certificate Location) --server-name (Domain Name)
I'm pretty new to Linux and using both Mod-wsgi as well as Apache so any help is greatly appreciated.
I suppose it is not good way to resolve this problem.
I recommend you use monit (https://mmonit.com/). It is cool program for checking services.
apt-get install monit
Apache restart configuration directives:
check process httpd with pidfile /var/run/httpd.pid
group apache
start program = "/etc/init.d/httpd start"
stop program = "/etc/init.d/httpd stop"
if failed host 127.0.0.1 port 80
protocol http then restart
if 5 restarts within 5 cycles then timeout
You are better off using the --setup-only option to mod_wsgi-express or the Django integration for it, to generate the configuration but not run it. Then as others have mentioned, integrate it into the system service manager.
The two commands for starting and stopping the Apache/mod_wsgi instance would be apachectl start and apachectl stop, where apachectl is that which was generated when running with the additional --setup-only option.
When running it as a system service, also make sure you use the --server-root option to specify a more persistent location for the generated configuration. Do not use the default under /tmp if running for anything but temporary development sessions as some Linux systems will remove files under /tmp causing things to start failing after a while.
Also, since under a service manager it would generally be starting as root, particularly if listening on port 80 is a requirement, ensure you use the --user and --group options to specify what user/group your Python web application should run as.
Read:
https://pypi.python.org/pypi/mod_wsgi
for more details of the --setup-only option and start-server commands for generating the configuration. Because you are using the Django integration, you will need to use the --setup-only option.
For more informed helped, bring your issue to the mod_wsgi mailing list. The mod_wsgi-express way of running Apache/mod_wsgi is new enough that unlikely that anyone here is really going to know much about it.
There is no need to do this at all. There is no reason to start up Apache manually; once it's installed as a system service, Ubuntu will start it up automatically on restart or crash.
You should reflect on why you feel the need to do this for Apache specifically, and not any of the other system services you depend on, such as the database.