This question already has answers here:
Make child process spawned with system() keep running after parent gets kill signals and exits
(2 answers)
Closed 3 years ago.
The program processA is a Linux service, launched by "systemctl start processA".
This process will call std::system to run a shell script to upgrade software.
The script will run "systemctl" to stop processA first, then replace some executable files, finally restart processA.
The problem is that when "systemctl stop processA" is executed, the script is also terminated.
How to solve it?
I had tried to run the script file in terminal; it works. So there is not a problem with the script.
//this is how the script is called
int rs = std::system("/usr/bin/update_server.sh upgrade \"/tmp/firmware\" > \"/tmp/upgrade.log\" 2>&1");
systemd will also kill child processes (after all, that's what's usually desired), so you can't do the upgrade from the service.
You can, however create a oneshot service to upgrade the binary that conflicts with the main service. To upgrade, you stop the service, run the upgrade service and then start the service again.
Related
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 have written up a simple bash script that will copy the newest image from my ip camera into a directory, rename the file and delete the old file. The script loops every 10 seconds.
I want to have this script start running in the background and run continuously all the time that the server is up.
I understand the part about adding a & to the end of the command will cause it to run in the background.
Is init.d the best place to execute this?
I am running ubuntu server.
This sort of thing is normally done by service scripts, which you would find under /etc/init.d. Depending on the version, that might be a "System V init script", or one of the systemd scripts.
A simple service script of the sort you are asking about would start automatically (based on comments in the script's header that tell what run-levels it would use), create a file under /var/run telling what process-id the script uses (to allow killing it), and run the copying in a loop, calling sleep 10 to space the timing as indicated.
A typical service script should implement "start", "stop", "restart" and "status". Not all do, but there is rarely a good reason to not do this.
On my (Debian) system, there is a README file in the directory which is a good introduction to the topic. There are several tutorials available for the topic. Here are a few:
Linux: How to write a System V init script to start, stop, and restart my own application or service
Writing a Linux Startup Script
Manage System Startup and Boot Processes on Linux with Upstart
This question already has answers here:
How can I run Perl system commands in the background?
(4 answers)
Closed 8 years ago.
I am running a Perl script in which I need to start a tomcat server. After starting the server I need to execute a different linux command.
In the Perl script after starting tomcat it isn't coming out to the next line as tomcat sever is running..
system("tomcat.sh run >log.txt");
system("ls");
I tried to open the server in different terminal. But control remains there itself.
system("xterm", "-hold", "-e", " tomcat.sh run");
I tried exec in place of system but the behaviour is same.
If you use the single string version of system then you can append an & to run your command in the background:
system("tomcat.sh run >log.txt &");
Should do the trick.
I also found a similar question here
This is because system blocks until the process finishes. I'm not sure on how to deal with such situation, you might fork it, close STDIN before you run external process etc. Instead of system, you might try IPC::System::Simple, which handles a lot of platform-specific details for you, or modules like IPC::Run or IPC::Open3.
Similar to your issue: Why does my jzip process hang when I call it with Perl's system?
I am running a automatic installation in linux by running some command in cli
root#server$ sudo install some-devl
if unfortunatly even before the installation finishes the console become closed (putty to assume )
we can check if that is running or not by relaunching and running putty again with login
ps -eaf | grep install*
but is the anyway to continute to show in install output on screen again ?
One way to make your session resilient to disconnections is to use the screen command.
Another thing to try is to prevent the disconnects in the first place. One way is to set a keep alive.
I wrote a simple JAVA application which runs as a service. When my application is up and running, I maintain the PID in a file which will be used while stopping the application.
Issue:
When I restart the OS the stop script is not called (not sure how to make this happen) and the old PID is left as it is in the PID file. Now, after reboot (which start my app) when I stop the app using stop script now my stop script will try to clean up all the PID listed in the file. Most of the time, I will get "No such process". But there are chance the same PID might have been used for some other process
Question:
How I can make sure my stop script will be invoked when I shutdown ore reboot the OS? I am looking a solution for RHEL environment.
I think your are looking for a init script. (startup/shutdown services at different run levels)
This is a good reference
http://blog.rimuhosting.com/2009/09/30/one-java-init-script/
this has a good refernce to Linux init.d scripts
http://coreymaynard.com/blog/creating-a-custom-initd-script-on-fedora/
Hope it helps
If you are looking for scripts that run after reboot, I guess you can write the script in /etc/rc.local and then you can start your service.
This script will run after all your init scripts have run while your machine starts. Using this you can delete the old PID file.