[SOLVED]python exit does not exit

I am trying to understand why the attached code does not exit when started with indigohost -x
the signals ctrl and kill are handled correctly:
signal --> exit_func --> loop --> main

but at end of main it stops but the process indigohost does not stop. -- return() does not do anything and exit() throws an indigo error

do I need to kill -9 the PID in the program to terminate itself/indigohost as indicated?

When using the program with regular python it exits fine

Karl

Code: Select all

import sys, time, signal, os

def exit_func(signum, func=None):
   global quitNow
   quitNow = 'yes'
   print 'exit call with ' + quitNow + ' ' +str(signum)
   return (0)

def theloop():
   global quitNow
   while quitNow == 'no':
      print 'in   loop ' + quitNow
      time.sleep(3)
   print ' in theloop program ' + quitNow
   return (0)


if __name__ == "__main__":
   global quitNow
   quitNow ='no'
   myPID = str(os.getpid())
   print 'pid: ' + myPID

   signal.signal(signal.SIGTERM, exit_func)
   signal.signal(signal.SIGINT,  exit_func)
   retCode =theloop()
   print ' in main program ' + quitNow
   os.system('kill -9 ' + myPID)
##   return (0)
##   sys.exit()   



[jay (support)]

I suspect it's because your script is never getting those signals - remember that starting an indigohost process isn't just starting a python interpreter - it's actually starting an indigohost application instance (which is an application that we wrote) and that process is eating those signals rather than passing them through to the script. What exactly are you trying to do?

it actually gets the signals and with the "kill" at the end it ends, but with return(0) or exit() it does not

[jay (support)]

The indigohost process raises a SIGTERM after the script finishes executing before returning - but since you redirected it to your script and your script is now done (it's the host process that's hung up, not your script - you can just end with the last print statement) there's nothing to catch the SIGTERM. Unfortunately, you can't just save off the old handler before changing it to your handler because it's a C++ call not a python handler so you can't restore it.

What exactly are you trying to do?

[jay (support)]

Here's a workaround: don't redirect signal.SIGTERM (since IPH needs it) - rather, use one of the other ones like signal.SIGHUP. Then, send it SIGHUP (kill -1 PID) to stop the process externally and your main will exit nicely (no need for anything past the last print).

here is what I am trying to do:

a python program that runs in the background:
it sleeps for 5 seconds, checks things and if there are any changes, update indigo variables and then sleeps again for 5 secs
if indigo wants to stop it, it has to tell it somehow to finish.

So here is what i need: how should i start this python script and how will indigo tell it to end - it should get a signal to finish reads and writes etc.

Looking that the plugins (I am still not proficient on how to use that setup) it looks to me that its about switching individual devices on/off etc.

thanks

Karl

[jay (support)]

While most plugins do in fact present devices, that's not necessary. For instance, we have a plugin (now hidden but a plugin nonetheless) called the Action Collection which is just a bunch of actions.

You could create a plugin that didn't expose any devices - and, in fact, didn't even expose any actions, events, menus, or config. It would simply start up, execute the runConcurrentThread() method (which is where you'd put your looping construct which would also update variables) and catch the exception that Indigo throws when it's time to stop. You could have a plugin config dialog that allowed you to specify the variables you want to use but even that's not necessary.

BTW, have you looked at the Cynical Network plugin? I believe it allows for a certain level of generic network communication and may do what you need assuming that it's actually a network connection that you're querying.

The other option would be to write a pure Python script (not running in the indigo host) that uses the RESTful API to update variables. You can have a startup trigger start the script (using the Run Shell Script action, just make sure you have he shebang at the top of the script) and then inside the script if the RESTful call fails (meaning that IWS isn't running) then exit the script.

I have attached my understanding of the code needed to just start and stop a basic plugin

is this correct?
and is start_myProg indented correctly i.e. is part of the class Plugin

Karl

Code: Select all

#! /usr/bin/env python
# -*- coding: utf-8 -*-
####################
# Copyright (c) 2013, Perceptive Automation, LLC. All rights reserved.
# http://www.perceptiveautomation.com

import indigo

import os
import sys
import time

# Note the "indigo" module is automatically imported and made available inside
# our global name space by the host process.

################################################################################
class Plugin(indigo.PluginBase):
   ########################################
   def __init__(self, pluginId, pluginDisplayName, pluginVersion, pluginPrefs):
      indigo.PluginBase.__init__(self, pluginId, pluginDisplayName, pluginVersion, pluginPrefs)
      self.debug = True

   def __del__(self):
      indigo.PluginBase.__del__(self)



   ########################################
   def startup(self):
      self.debugLog(u"startup called")
      global quitNOW
      quitNOW ='no'
      start_myProg()

      
   def shutdown(self):
      self.debugLog(u"shutdown called")
      global quitNOW
      quitNOW ='yes'

   def start_myProg()
      global quitNOW

      while quitNow == 'no'
         #do my thing ###
         #do my thing ###
         #do my thing ###
         #do my thing ###
         time.sleep(5)
   
      #### clean up when quitNOW !='no'

      return (0)


I wouldn't code it up quite how you have it... It would be easiest/best in your case to let Indigo generate a new thread for you - you can actually just start performing your loop in the runConcurrentThread method that is called (this is in the Plugin class):

Code: Select all

def runConcurrentThread(self):
    try:
        while True:
            # Do your stuff here
            self.sleep(5) # in seconds
    except self.StopThread:
        # do any cleanup here
        pass


thx will try that

works nicely, thanks so much... my first real plugin is live ~ 700lines of code..

one more question:

what is the difference between __init__ and startup from a plugin point of view.
are they called just sequentially or what happens between init and startup?

Code: Select all

   ########################################
   def __init__(self, pluginId, pluginDisplayName, pluginVersion, pluginPrefs):
      indigo.PluginBase.__init__(self, pluginId, pluginDisplayName, pluginVersion, pluginPrefs)
      self.debug = True

   def __del__(self):
      indigo.PluginBase.__del__(self)

   ########################################
   def startup(self):
      self.debugLog(u"startup called")

   def shutdown(self):
      self.debugLog(u"shutdown called")

   ########################################


[jay (support)]

From a practical standpoint, they're called sequentially.

ok.. one more:

without plugin running can I enter anything into /plugins/plugin-name/configure/ .. not visible since it is not enabled

only after plugin is enabled i see "configure"

I need to enter a parameter before plugin really starts working.

I tried to wait for an entry with
"
while True
sleep(30)
self.pluginPrefs.get (...,...)
if parameter ok: break
"
in startup(self) and runConcurrentThread(self) --
but I get the color wheel if I want to open /plugin/plugin-name/configure while startup or runConcurrentThread tries to read pluginconfig

any advice?

Karl

[jay (support)]

In your loop you need to see if the configurable value is available - if not then just don't do anything. Basically, your just waiting for it to be correctly configured. That's the standard way that plugins should handle that scenario. It is basically the same as when a plugin is misconfigured (for instance a bad port or file name).