Stop Python Program After Autostarted in rc.local with all i

[bitsbeauty]

I have python program wich nicely autostarts after power on. Therefore I just put in the

Code: Select all

rc.local 

the line:

Code: Select all

/home/pi/PythonProgramm.py 

before the

Code: Select all

exit 0

As I said, that works perfectly, but how can I stop the program? The keyboard on the usb-port is not reacting on smthg, and via ssh I can login as

Code: Select all

root

or

Code: Select all

pi

, but nothing happen. I wouldn't like to "kill" the process because there are several subprocesses running, which I'd like to end when the program stops. So far as I understand "kill" doesnt end the subprocesses right?

Anyone has an idea? At the moment I can just see the running program on the pi HDMi Port which shows a video.

[rurwin]

Some bedtime reading for you:

Code: Select all

$ man kill
$ man 7 signal
$ kill -l

tl;dr: You can send a "keyboard interrupt" signal to the process using kill -INT <pid>

[bitsbeauty]

Thanks for you fast reply. As far as I understand you, I have to type

Code: Select all

kill -3 2645

when I want to kill the PID: 2645 with SIGQUIT signal. Is that right?

When I do so, it just nothing happens. The PID is still there when I give a list withps aux
I'M logged in over ssh as root user.

[bitsbeauty]

Sorry, Process gets killed. But the subprocesses still remain. Whats the difference to pressing ctrl+c in terminal to exit a program? Is there a corresponding signal?

[rurwin]

Erm...

That's what I said.

tl;dr: You can send a "keyboard interrupt" signal to the process using kill -INT <pid>

QUIT is rather more brutal.

You should also not check for "except: KeyboardInterrupt" in your code, but rather use a "finally:", which will run your cleanup code when the process terminates for whatever reason... Although some signals may be too much for any remedial action.

[bitsbeauty]

That's what I said.
tl;dr: You can send a "keyboard interrupt" signal to the process using kill -INT <pid>

..well you never know if -INT is a command or tells you to add an Integer Number;-)

So I use "except: KeyboardInterrupt" in my code, but the cleanup is done after "finally:". For some reasons the process can't be killed with -2 (Interrupt from keyboard) - Nothing happens.
-3 (Quit from keyboard) is working, but the "finally:" cleanup isn't processed.
Thanks a lot for your help, I already learned something. Do you have any more suggestions about that?

[rurwin]

Does this help?
https://docs.python.org/2/reference/com ... -statement

quit-from-keyboard is ctrl-\ It is designed to allow you to terminate a program and create a memory dump so you can debug the program. Useless in Python of course and mostly archaic. IIRC, memory dumps are disabled on the Pi anyway. It does have its uses when a program is ignoring ctrl-C.

I would remove the except: KeyboardInterrupt and just use finally: I don't know why you are having a problem, unless the except clause is calling exit() or something similar. It should run the except clause and then the finally clause.

[bitsbeauty]

I use

Code: Select all

try:
   ... (main programm loop)
except:
   import traceback
   print traceback.format_exc()
finally:
   ....(cleanup)

I dont know why, but it isnt running the "cleanup" methodes when I kill the process. Doesnt differ with different signal Numbers.
So Only thing what I can do at the moment is toll kill all the subprocesses manually..

[QuietZone]

OP, please ignore all the (well-intentioned, but wrong) responses so far on this thread.

None of the ideas or methods proposed so far have any relevance to the issue at hand. Nothing about signals or killing processes and so on is relevant.

Short summary: You have hosed your card and you will need to use an out-of-band repair method to fix it. There are various ways to do this - the easiest (assuming you do not have access to another Linux system) is to stick the card into a Windows machine and edit the file "cmdline.txt" and append:

Code: Select all

 init=/bin/bash

to the end of the (single) line in that file. Note that the space before "init" is critical.
Once you've done this, you'll be able to boot the card on the Pi and get to a root shell prompt, from whence you can fix your /etc/rc.local file.

Longer summary: When you run stuff in rc.local, it runs "synchronously", which means that nothing else will run until the process exits. Worse, for security reasons, all interrupts and such like are turned off at this stage of the boot process. So, when you run something in rc.local, if it doesn't exit, you're stuck.

Other people will chime in momentarily with the fixes/workarounds for this behavior.

[DougieLawson]

That is NOT true with systemd systems, /etc/rc.local is not single threaded and given exclusive control. You can use the magic SysRq keys to interrupt a hanging task during boot and the system will usually recover to a login prompt (even if the network doesn't come up active).

Also editing the command line with Windows is NOT possible if the card has NOOBS. You have to use the NOOBS recovery system to edit it. Running a root shell from init=/bin/bash isn't "easiest".

[QuietZone]

That is NOT true with systemd systems, /etc/rc.local is not single threaded and given exclusive control. You can use the magic SysRq keys to interrupt a hanging task during boot and the system will usually recover to a login prompt (even if the network doesn't come up active).

Yes, I'd heard that - that this issue was "fixed" in systemd (Jessie). Still, OP did not specify which version of Raspbian he is running, and the problem description fits the "locking up in rc.local" problem case to a T. So, I'm assuming that he's still running the older version of Raspbian.

Or, that there is some edge/corner case that causes it to lock up in Jessie like it does in Wheezy...

Also editing the command line with Windows is NOT possible if the card has NOOBS. You have to use the NOOBS recovery system to edit it. Running a root shell from init=/bin/bash isn't "easiest".

Also true. But basically an implementation detail.

JOOC, why do you say it isn't "easiest" ?

[DougieLawson]

Because the easiest is another SDCard and a USB SDcard reader. That means the person with the borked SDCard ends up building themselves a rescue system, they don't lose anything if it works, they gain some experience. Repairing the borked card is swap SD, boot, shell, sudo -i, fsck -f -y /dev/sdaX, shutdown, swap cards back and run. No funky edits, no messing about, no other computer needed (except to build the new SDCard, which they've already done on day one).

Go and stick your requirements in viewtopic.php?f=28&t=107519 where there's someone who has forked NOOBS.

[bitsbeauty]

Dear QuietZone,

I havent hosed my SD card and can still access everything. When the programm is started from the rc.local, I can kill the process after log-in via SSH. So no need to fix my SD card. I just looking for a way to end the subrocesses when I kill my python script.

best
bitsbeauty