creating a daemon?

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • bmgx

    creating a daemon?

    This is what I am trying to find out, instruction on how to create a
    simple daemon on unix systems(Linux), can't find any info on usual sources..

  • Diez B. Roggisch

    #2
    Re: creating a daemon?

    bmgx wrote:
    [color=blue]
    > This is what I am trying to find out, instruction on how to create a
    > simple daemon on unix systems(Linux), can't find any info on usual
    > sources..[/color]

    google: daemonize python fork

    Works perfect for me.

    Diez

    Comment

    • Harry George

      #3
      Re: creating a daemon?

      bmgx <bmgx_no_sp@mgl eesonprop.co.za > writes:
      [color=blue]
      > This is what I am trying to find out, instruction on how to create a
      > simple daemon on unix systems(Linux), can't find any info on usual
      > sources..
      >[/color]

      1. The idea is to fork, clean up all the inheritable stuff like files
      and environment vars, and then fork again. The resulting process
      can then be left running to do the daemon work. I recall there is
      a daemon.py module somewhere which does this all for you. Here are
      the basics:

      def main(args):
      #---first fork---
      try:
      pid = os.fork()
      if pid > 0:
      #---first parent---
      sys.exit(0)
      except OSError,e:
      print >>sys.stderr, "fork #1 failed %d (%s)" % (e.errno,e.stre rror)
      sys.exit(1)


      #---make a clean process---
      os.chdir('/')
      os.setsid()
      os.umask(000)
      child_in =open('/dev/null','r')
      child_out=open( '/dev/null','w')
      os.dup2(child_i n.fileno(), sys.stdin.filen o())
      os.dup2(child_o ut.fileno(), sys.stdout.file no())
      os.dup2(child_o ut.fileno(), sys.stderr.file no())

      #---second fork---
      try:
      pid = os.fork()
      if pid > 0:
      #---second parent---
      sys.exit(0)
      except OSError,e:
      print >>sys.stderr, "fork #2 failed %d (%s)" % (e.errno,e.stre rror)
      sys.exit(1)


      #---in clean child---
      x=MyApp()
      x.run()


      2. To talk to that daemon, you can use a) files at known locations, b)
      pipes (see popen), c) sockets with ad hoc protocols (see asyncchat
      and SocketServer), d) predefined protocols (see Internet Protocols
      and Services). The various "server" modules have the setup code
      from "1" above builtin, so you can ignore that level of detail.
      ["see" references can be found in the normal python documentation's
      Library Reference"].

      3. Once you have a working daemon, you need a way to start and stop
      it. You could manually start it each time you need it and then
      "kill" it when done. More commonly you would do it (in Linux and
      UNIX) via a boot-time initialization script (typically found in
      /etc/init.d). Each *NIX has its own flavor of setting these up, so
      you need to look at existing services and maybe copy-and-edit a
      working script.

      4. If security is an issue (it probably is), you may also want to hide
      the service behind xinetd. That is a whole setup story in its own
      right. And if security is really troublesome, you may need to
      assure the python interpreter itself is safe. That kind of
      consideration is way out of my league.

      --
      harry.g.george@ boeing.com
      6-6M31 Knowledge Management
      Phone: (425) 342-5601

      Comment

      • bmgx

        #4
        Re: creating a daemon?

        Yeah ok, "FORK" being the golden word I failed to see at first, got some
        answers @ google groups but the most helpful was this link:



        now to stick those DAEMONS with my fork()! anyone have an os.knife()?

        Harry George wrote:[color=blue]
        > bmgx <bmgx_no_sp@mgl eesonprop.co.za > writes:
        >
        >[color=green]
        >>This is what I am trying to find out, instruction on how to create a
        >>simple daemon on unix systems(Linux), can't find any info on usual
        >>sources..
        >>[/color]
        >
        >
        > 1. The idea is to fork, clean up all the inheritable stuff like files
        > and environment vars, and then fork again. The resulting process
        > can then be left running to do the daemon work. I recall there is
        > a daemon.py module somewhere which does this all for you. Here are
        > the basics:
        >
        > def main(args):
        > #---first fork---
        > try:
        > pid = os.fork()
        > if pid > 0:
        > #---first parent---
        > sys.exit(0)
        > except OSError,e:
        > print >>sys.stderr, "fork #1 failed %d (%s)" % (e.errno,e.stre rror)
        > sys.exit(1)
        >
        >
        > #---make a clean process---
        > os.chdir('/')
        > os.setsid()
        > os.umask(000)
        > child_in =open('/dev/null','r')
        > child_out=open( '/dev/null','w')
        > os.dup2(child_i n.fileno(), sys.stdin.filen o())
        > os.dup2(child_o ut.fileno(), sys.stdout.file no())
        > os.dup2(child_o ut.fileno(), sys.stderr.file no())
        >
        > #---second fork---
        > try:
        > pid = os.fork()
        > if pid > 0:
        > #---second parent---
        > sys.exit(0)
        > except OSError,e:
        > print >>sys.stderr, "fork #2 failed %d (%s)" % (e.errno,e.stre rror)
        > sys.exit(1)
        >
        >
        > #---in clean child---
        > x=MyApp()
        > x.run()
        >
        >
        > 2. To talk to that daemon, you can use a) files at known locations, b)
        > pipes (see popen), c) sockets with ad hoc protocols (see asyncchat
        > and SocketServer), d) predefined protocols (see Internet Protocols
        > and Services). The various "server" modules have the setup code
        > from "1" above builtin, so you can ignore that level of detail.
        > ["see" references can be found in the normal python documentation's
        > Library Reference"].
        >
        > 3. Once you have a working daemon, you need a way to start and stop
        > it. You could manually start it each time you need it and then
        > "kill" it when done. More commonly you would do it (in Linux and
        > UNIX) via a boot-time initialization script (typically found in
        > /etc/init.d). Each *NIX has its own flavor of setting these up, so
        > you need to look at existing services and maybe copy-and-edit a
        > working script.
        >
        > 4. If security is an issue (it probably is), you may also want to hide
        > the service behind xinetd. That is a whole setup story in its own
        > right. And if security is really troublesome, you may need to
        > assure the python interpreter itself is safe. That kind of
        > consideration is way out of my league.
        >[/color]

        Comment

        Working...