Answer the question
In order to leave comments, you need to log in
Answer the question
In order to leave comments, you need to log in
In order for the program to work "in the background", it must either take care of itself not to block the console and not die when the bash is closed, or entrust this to a special program.
How to go into the background yourself:
Processes (running programs) have IDs and know who started them by storing the id of the parent process. That. we have a process tree. A parent process can control child processes, and it must terminate its child processes when it terminates. If it does not, then the child process will change its parent to a process with id = 1, i.e. to the init process. Therefore, in order to go into the background, your program should only stop its parent process.
The problem is that the parent process for the program you're running in the console is the console itself, and we don't want it to close.
Therefore, programs going into the background increase the nesting level before stopping the parent - i.e. run their copy, and this copy, being a child of the first process of the program, kills not bash, but the auxiliary parent process.
Another point is to get rid of the console. Everything is simple here - you need to redirect stdin, stderr and stdout to files.
And finally, we need to take care of managing the daemon, because so far we have no choice but to send signals to it with the kill command. To implement more understandable commands, you need to do two things:
1) while going into the background, save to the pid file of the resulting process
2) write some code in the program itself or in a helper script that, when called in the console, will read the pid from the file and manipulate the process.
Such functionality is often allocated in a separate library, you can search in the documentation or on the github.
Another option is to use helper programs.
On the one hand, we have the capabilities of the bash itself - jobs i.e. background processes, which however die when the console is closed. To get around this, there is the disown command and the nohup and setsid programs.
They allow one way or another to get the process untied from the bash. However, the process can only be controlled by signals.
On the other hand, there are process managers. For example supervisord or pm2. These are programs that can go into the background and can, already being a daemon, launch and control other programs.
And finally, there is always the main process manager of your computer / server - this is the initialization system, which is now almost everywhere - systemd. It does the same thing as a regular process manager, but also allows you to control the sequence of starting processes.
Bottom line: it is necessary to choose a method for daemonizing a process based on the stability of its operation. If this is a server that should work for months and start at system startup, then you need to use the initialization system. That's what web servers, databases, and all sorts of capital services do.
If the processes are more dynamic and they need to be started and stopped periodically, then it is better to take a process manager.
If this is a very fleeting desire to run the program in the background, let it work and stop there, then you can not bother and untie it from the bash in one way or another.
The ability to independently go into the background and implement your own process control commands is needed only if you have Napoleonic plans and want to give users the opportunity to run your program on different operating systems.
On linux, the best option would be to make a systemd service file for the script.
https://stackoverflow.com/questions/13069634/pytho...
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question