Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #77801 > unrolled thread

Re: Example of python service running under systemd?

Started byChris Angelico <rosuav@gmail.com>
First post2014-09-12 18:15 +1000
Last post2014-09-12 18:15 +1000
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Example of python service running under systemd? Chris Angelico <rosuav@gmail.com> - 2014-09-12 18:15 +1000

#77801 — Re: Example of python service running under systemd?

FromChris Angelico <rosuav@gmail.com>
Date2014-09-12 18:15 +1000
SubjectRe: Example of python service running under systemd?
Message-ID<mailman.13968.1410509703.18130.python-list@python.org>
On Fri, Sep 12, 2014 at 4:18 PM, Ervin Hegedüs <airween@gmail.com> wrote:
> is there any other reason outside the debugging?
>
> Of course, I've handled that in a simple way:
>
>     parser = optparse.OptionParser()
>
>     parser.add_option("-d",
>                       "--debug",
>                         action="count",
>                         dest="debug_mode",
>                         help="Start process in debug mode, not forking.")
>
>     (options, args) = parser.parse_args()
>
>     debug_mode = True
>     if options.debug_mode is None:
>
>         debug_mode = False
>         try:
>             pid = os.fork()
>             if pid > 0:
>                ....
>
> And of course, I've handled the signals, logfiles and so on...

1) You don't need all of the above code.
2) You don't need to test all of that code.

And that code is significantly abbreviated. In reality it's quite a bit longer.

Having less code branches is itself an advantage. If I can accomplish
everything with simple top-down code, why go for a -d option and then
an alternative method that forks, forks again, handles signals, etc,
etc, etc? (Although handling signals may still be important, if I want
some kind of more orderly shutdown on SIGTERM, or if I want SIGHUP to
do some sort of reload - not usually in Python, but my Pike code
generally takes SIGHUP to mean "reload your code from the disk".) The
simpler, the better. Less code => less bugs.

ChrisA

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web