Easy customizable python daemon
At some point I needed to demonize some action on python. There were a lot of examples of similar activities of varying degrees of concentration in the network. Since in the future it was supposed to use the code of demonization in further activities, I decided to spread the settings and the demon itself to different parts.
As a result, there were three files:
Then I will try to describe the logic of the work of all three.
I must say that everything is on Github . Because if you read a python easily, it can be much more difficult to read my very incompetent text.
Actually there is really nothing to describe in the first file: These are almost unchanged three classes taken from this article . Of the changes there is only that the class of the signal handler was attached to the daemon itself, and adding the signals to the list of processors was screwed into the actual demonization procedure.
')
The second part will be a little more interesting. There are three classes there:
1) SigFunctionsCon - contains the response to the signals. Upon initialization, it receives an instance of the daemon in order to be able to access its methods. Each method must correspond to the signal that it processes with the name. For example:
Internal methods and fields can be anything.
2) ReactFunctionCon - contains a response to console commands. When initialized, it also gets a daemon. Each method by name must correspond to the command to which it will react and may take arguments (that which actually follows the command in the command line). For example:
3) StatCon - contains all sorts of static daemon settings. At the moment it looks like this:
Accordingly -
HELP is a string that is output when arguments are incorrectly passed to a function (Perhaps a default help command should be made that displays this message?).
The run method is actually what it was all about — what the demon is doing.
The address of the pid file is for storing the process and all that.
Input, output, errors - logging and so on. By default, sent to / dev / null
The center script is of interest only code. In general, it inherits the daemon class, collects all settings from the previous file and decomposes them by daemon, and accepts commands.
Well, actually the questions:
What's wrong, what's not so?
How do you think you should somehow attribute to this GPL, or shouldn't you be a big boss, and this is all too frivolous?
Do I adequately indicate the previous authors?
Thank you in advance.
References:
Github
Original script
As a result, there were three files:
- Parental classes - with a slight change of classes taken from Internet articles
- Setup classes - reaction to signals, reaction to commands and a set of static settings for launching
- Startup script - collects the first two in the actual demon
Then I will try to describe the logic of the work of all three.
I must say that everything is on Github . Because if you read a python easily, it can be much more difficult to read my very incompetent text.
Actually there is really nothing to describe in the first file: These are almost unchanged three classes taken from this article . Of the changes there is only that the class of the signal handler was attached to the daemon itself, and adding the signals to the list of processors was screwed into the actual demonization procedure.
')
The second part will be a little more interesting. There are three classes there:
1) SigFunctionsCon - contains the response to the signals. Upon initialization, it receives an instance of the daemon in order to be able to access its methods. Each method must correspond to the signal that it processes with the name. For example:
def SIGTERM(self): sys.stderr.write("BB!\n") sys.exit(0) Internal methods and fields can be anything.
2) ReactFunctionCon - contains a response to console commands. When initialized, it also gets a daemon. Each method by name must correspond to the command to which it will react and may take arguments (that which actually follows the command in the command line). For example:
def stmess(self,message): print message self.__ourdaemon.start() 3) StatCon - contains all sorts of static daemon settings. At the moment it looks like this:
class StatCon: Help = "Autmation has be applied to distribution sistem feeder for a long time, aspecially as related to protection and the restoration of some parts of the feeder." def run(self): while(True): time.sleep(1) PidFile = "/tmp/daemon-naprimer.pid" Inputter = "/dev/null" Outputter = "/dev/null" Errorer = "/home/espresso/lid" Accordingly -
HELP is a string that is output when arguments are incorrectly passed to a function (Perhaps a default help command should be made that displays this message?).
The run method is actually what it was all about — what the demon is doing.
The address of the pid file is for storing the process and all that.
Input, output, errors - logging and so on. By default, sent to / dev / null
The center script is of interest only code. In general, it inherits the daemon class, collects all settings from the previous file and decomposes them by daemon, and accepts commands.
Well, actually the questions:
What's wrong, what's not so?
How do you think you should somehow attribute to this GPL, or shouldn't you be a big boss, and this is all too frivolous?
Do I adequately indicate the previous authors?
Thank you in advance.
References:
Github
Original script
Source: https://habr.com/ru/post/176067/
All Articles