Easily customizable python daemon
At some point, I needed to demonize some action in python. A bunch of examples of similar activities of varying degrees of concentration were lying on the network. Since in the future it was supposed to use the demonization code in further activities, I decided to distribute the settings of the daemon itself to different parts.
As a result, there were three files:
Next, I will try to describe the logic of all three.
I must say right away that everything is on Github . Because if you read python easily, reading my very inept text can be much more difficult.
Actually in the first file there is really nothing to describe: These are almost unchanged three classes taken from this article . Of the changes there, only that the signal handler class was attached to the daemon itself, and adding signals to the list of processed ones was screwed into the demonization procedure itself.
The second part will be a little more interesting. There are three classes:
1) SigFunctionsCon - contains a reaction to 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 the name. For example, like this:
Internal methods and fields can be anything.
2) ReactFunctionCon - contains a reaction to console commands. Upon initialization, it also receives a daemon. Each method by name must correspond to the command to which it will respond and can take arguments (what actually follows the command on the command line). For instance:
3) StatCon - contains all sorts of static daemon settings. At the moment it looks like this:
Correspondingly, a
help line is displayed when arguments are incorrectly passed to any function (Perhaps you should make a default help command that displays this message?).
The run method is actually what it was all about — what the daemon does.
The pid file address is for storing the process and all that.
Input, output, errors - logging and more. By default, it is sent to / dev / null. The
center script is of interest exclusively by code. Generally speaking, it inherits the daemon class, collects all the settings from the previous file and decomposes them by daemon, and accepts commands.
Well, actually the questions:
What is wrong, what is not so?
How do you think should you somehow attribute the GPL to this, or should you not hurt, and is all this too frivolous?
Have I indicated the previous authors adequately enough?
Thanks in advance.
Links:
Github
Original Script
As a result, there were three files:
- Parent classes - with a slight change, classes taken from online articles
- Setting classes - reaction to signals, reaction to commands and a set of static settings for starting
- Launch script - collects the first two in the daemon itself
Next, I will try to describe the logic of all three.
I must say right away that everything is on Github . Because if you read python easily, reading my very inept text can be much more difficult.
Actually in the first file there is really nothing to describe: These are almost unchanged three classes taken from this article . Of the changes there, only that the signal handler class was attached to the daemon itself, and adding signals to the list of processed ones was screwed into the demonization procedure itself.
The second part will be a little more interesting. There are three classes:
1) SigFunctionsCon - contains a reaction to 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 the name. For example, like this:
def SIGTERM(self):
sys.stderr.write("BB!\n")
sys.exit(0)
Internal methods and fields can be anything.
2) ReactFunctionCon - contains a reaction to console commands. Upon initialization, it also receives a daemon. Each method by name must correspond to the command to which it will respond and can take arguments (what actually follows the command on the command line). For instance:
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"
Correspondingly, a
help line is displayed when arguments are incorrectly passed to any function (Perhaps you should make a default help command that displays this message?).
The run method is actually what it was all about — what the daemon does.
The pid file address is for storing the process and all that.
Input, output, errors - logging and more. By default, it is sent to / dev / null. The
center script is of interest exclusively by code. Generally speaking, it inherits the daemon class, collects all the settings from the previous file and decomposes them by daemon, and accepts commands.
Well, actually the questions:
What is wrong, what is not so?
How do you think should you somehow attribute the GPL to this, or should you not hurt, and is all this too frivolous?
Have I indicated the previous authors adequately enough?
Thanks in advance.
Links:
Github
Original Script